Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-08-19
2001-01-30
Coulter, Kenneth R. (Department: 2758)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06182158
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The method and system of the present invention relates generally to the field of computer program interoperability, and, more particularly, to the field of facilitating interoperability between two or more processes which were initially written to execute on top of two different operating systems but instead execute on top of a third operating system.
2. Background of the Invention
A number of different operating system vendors are currently developing new operating systems. A design goal for some of these new operating systems is to provide interoperability among incompatible legacy applications running on top of the new operating system. For example, developers of the new Spring operating system from Sun Microsystems would like to provide interoperability between applications written for the Solaris 1.x family of operating systems and for the Solaris 2.x family of operating systems
1
. The problems with fulfilling this design goal are two-fold. First, the legacy applications are incompatible among themselves if they were written to run on top of different legacy operating systems. For example, a wordprocessing program written to run on top of the Solaris 2.4 operating system may be unable to interact with a spreadsheet program written to run on top of the Solaris 1.0 operating system. Therefore, a user of these application programs would be unable to create a compound document, such as a sales report, which included text from the wordprocessing program and spreadsheet cells from the spreadsheet program.
1.Sun, Solaris, and Sun Microsystems arc registered trademarks of Sun Microsystems, Inc. Spring is an in-ternal code name only and is not intended to represent either a trademark or a commercial product name.
Second, the legacy applications are incompatible with the new operating system because they were not written to run on top of the new operating system. Therefore, without further improvements, the legacy applications would be unable to run on top of the new operating system.
This incompatibility causes concern among users because users want seamless interoperability between their application programs. Users do not want to concern themselves with the details of compatibility and incompatibility at the operating system level. Likewise, such incompatibility concerns operating system developers because the inability of an operating system to provide interoperability among application programs adversely impacts the marketability of the new operating system.
To overcome these problems the developers of the present invention provide functionality in the new operating system to allow incompatible legacy applications to interact when executing on top of the new operating system.
An example using
FIGS. 1A and 1B
will help illustrate why applications written to run on top of different legacy operating systems are incompatible with one another and with the new operating system.
FIG. 1A
illustrates a first application program which runs on top of a first operating system. The computer system
100
of
FIG. 1A
includes a computer
101
, a memory
103
, a processor
105
, and an interface
107
. The memory
103
includes a first application program
109
and a first operating system
111
. To accomplish its functions, the first application program
109
makes calls to the first operating system
111
in a format compatible with the first operating system's application programming interface (“API”). The API is an abstract interface to the services and protocols offered by an operating system. The API usually provides a set of function calls which an application invokes to gain access to the operating system's services. The first operating system
111
accepts these calls from the first application program
109
, parses the calls to determine what system resource(s) need to be accessed in order to perform the function, performs the requested function by accessing the necessary system resource (e.g. a file) through a name space
112
associated with the first operating system, and returns the results to the first application program.
FIG. 2
illustrates a typical name space
200
used to access directories and files in a computer system. The name space
200
provides a mapping (also called a “binding”) between a set of file names
201
and their associated directories or files
203
. Given a file name
201
in a name space
200
, a user can “resolve” the file name to retrieve the associated file or directory (often called a context). It is important to note that a given file name is always interpreted relative to a particular name space. For example, a directory named “/sys/bin/operating_system,” when resolved relative to a name space for the first operating system
111
, could refer to a directory containing the binaries for the first operating system. However, when the same name is resolved relative to a name space for a different operating system, a different directory could be returned. In this way the directory names and file names passed along with the call to an operating system only refer to the directories and files in the name space of that operating system.
FIG. 1B
illustrates a second application program which runs on top of a second operating system. The computer
113
includes a memory
115
, a processor
117
, and an interface
119
. The memory
115
includes a second application program
121
, a second operating system
123
, and a second name space
124
. To accomplish its functions, the second application program
121
makes calls to the second operating system
123
in a format compatible with the second operating system's API. The second operating system
123
accepts these calls from the second application program
121
, performs the requested function by accessing files and directories through the second operating system's name space
124
, and returns the results to the second application program.
The API of the first operating system
111
is different than and therefore incompatible with the API of the second operating system
123
because it provides a different set of services and mandates use of a different set of interfaces than the API of the second operating system. Similarly, the name space
112
of the first operating system
111
is different than and therefore incompatible with the name space
124
associated with the second operating system
123
because it provides different bindings between directory or file names and the directories or files themselves.
This incompatibility problem can be addressed in at least two different ways. First, independent software vendors can “port” their application programs to the new operating system. While this solution is desirable, due to the cost of porting an application to a new platform this solution is not always viable. The developers of the present invention have therefore provided functionality in the new operating system to allow incompatible legacy applications to interact when executing on top of the new operating system.
SUMMARY OF THE INVENTION
An embodiment of the present invention provides an efficient and robust way to facilitate interoperability between two or more processes which were initially written to execute on top of two different operating systems but instead execute on top of a third operating system. Typically, the preferred embodiment begins by launching a parent process which was initially written to execute on top of a first operating system. The preferred embodiment then obtains a context object that implements a naming graph for the parent process. The context object includes bindings between a given set of names and an associated set of objects that are specific to the first operating system.
At some point during execution of the parent process, the parent process spawns a child process which was initially written to execute on top of a second operating system. Next, the parent process instantiates a copy of its context object. The parent process then performs a context merge operation which ensures that
Kougiouris Panagiotis
Madany Peter W.
Radia Sanjay R.
Shivanlingiah Anil S.
Beyer Weaver & Thomas LLP
Coulter Kenneth R.
Sun Microsystems Inc.
LandOfFree
Method and system for providing interoperability among... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for providing interoperability among..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for providing interoperability among... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2480888