Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1999-10-26
2003-08-19
Courtenay, III, St. John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06609158
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to object models, programming languages, and operating system services for use in a computing system. More particularly, the present invention relates to an architecture for supporting programming languages and multiple object models in a computer network with Novell NetWare software.
TECHNICAL BACKGROUND OF THE INVENTION
Computer languages have been proliferating, to the point that there are now hundreds of programming languages, with names ranging at least from “ABC” to “Y”. This proliferation is in stark contrast with the situation just a few decades ago when almost all programming was performed in assembly language or in a handful of higher-level languages such as FORTRAN, BASIC, and COBOL. Now dozens of language are in widespread use, with new languages and language versions being created all the time.
More programs tend to be written in newer languages, until these languages themselves age and fade into the background. For instance, FORTRAN was a very popular language in the 1960's for writing scientific applications, while C++ took off in the 1980's with its use of object-oriented programming, and JAVA, used for internet applications, has exploded in popularity since its birth in 1995.
Sometimes new programming languages solve problems more elegantly or simply than previous languages. For example, SQL is quite useful for performing database manipulations, and Java is known for its usefulness when programming Internet applications. Sometimes a program may be most easily written in a specialized language, as when an application for finding solutions to a differential equation is written in the math-oriented language Mathematica. A particular programming language may also be favored because the programmer knows the language well, because the language is readily available, and/or because support for the language exists within a particular organization.
For the foreseeable future programs will continue to be written in many different computing languages, and most computer-using companies will have applications and other programs written in a variety of languages. This can create problems.
For instance, a program written in one language often cannot communicate with a program written in a different language without tedious manual code modifications, and most likely, a round of testing and debugging. Bugs can be introduced into previously acceptable code when converting code from one language to another. Furthermore, some legacy programs may be written in languages that many current programmers never learned. If working programs (many of which have been thoroughly tested and debugged) could be reused without a tremendous amount of work on the part of an individual programmer, then program development and use could be greatly improved.
Many individual scripts or other programs written in a specific programming language could also be helpful in a different context, but there are barriers to their reuse. Sometimes a potential user does not know whether a particular script would be helpful because the user is unfamiliar with the specific instance of code. But more often scripts and other programs could be made available to those who could benefit from their use, if the effort needed to access the existing code in the different environment were not so tedious and time-consuming.
In addition to the proliferation of programming languages and programs written in different languages, reuse of earlier programming efforts is complicated by the fact that computer systems are increasingly distributed across networks. A wide variety of application programs such as word processors, spreadsheets, database managers, program development tools, and the like (collectively, “applications”) are found on one or more servers in a network. Sometimes a potential user does not know whether a particular application would be helpful because the user is unfamiliar with that application. Sometimes applications could be made available to those who could benefit from their use, but the necessary file access rights and execution environment have not been provided.
Several standards have been developed to help solve the problem of access across networks, but they also introduce the problem of conflicting standards. One widely used networking protocol model is the Object Request Broker (ORB) model, which allows programs in the form of “objects” to send messages to other objects across a network. However, there are three industry leading but somewhat incompatible implementations of the ORB model. CORBA (Common Object Request Broker Architecture)-allows objects written in any of several CORBA-enabled languages to invoke remote methods of other such objects. The Microsoft COM/ActiveX standard defines interfaces using language-neutral syntax, but ActiveX objects can usually communicate only when Microsoft platforms (such as those using the Windows/Windows NT operating system) are at both ends of the communication. RMI (Remote Method Invocation) allows Java objects access to other Java objects across a network, but not to other types of objects. Object models are also discussed in the Detailed Description. To overcome some of these incompatibilities, object bridges have been created to allow programs to interoperate despite the use of different object models.
Many current networking protocols require that programs be in the form of objects, and a multi-step process must be applied to each object class to remote-enable it. As mentioned earlier, ORB implementations may be incompatible. If an object previously enabled on one version of the standard wishes to talk to an object previously enabled in a different version, the protocols must be translated, and the source code classes must be modified. This modification must be done manually in many cases, although an object bridge may be used in some cases. If the object is to speak to an object which has been enabled on another protocol, then the translation process must be repeated for the other protocol. In short, if the code one wishes to reuse exists on a network, one often faces the task of locating the appropriate code, modifying it manually, and then using it across the network, as described above.
Prior approaches to the problems noted above, and to similar problems, provide limited help. For instance, conventional COM technology promulgated by Microsoft Corporation provides a binary object format requiring all objects to support an IUnknown interface to promote communication between COM objects. COM objects may be written in any of several languages which are supported by Microsoft for this purpose. But COM generally requires manual generation of a language library, provides little or no protocol bridging, and lacks an adequate facility for automatic generation of object stubs. Object stubs are communication modules that make it possible for an object to export its interfaces for use by other objects.
Relatively new ObjectSpace Voyager technology provides a general dynamic wrapping capability, including dynamic byte code generation and wrapping non-objects to make objects (Voyager is a mark of ObjectSpace, Inc.). Voyager technology has been used as a traditional bridge, that is, to bridge disparate object models. But prior to the present invention Voyager technology was apparently not used to bridge between programming languages to promote component reuse. ObjectSpace and ObjectBridge have also provided object model bridges, but to the inventor's knowledge neither addressed the issue of adapting an object for use by multiple languages.
It should also be noted that this technical background was written with knowledge of the present invention, which is a particular solution to problems noted here and/or noted below in the Detailed Description. One of ordinary skill who was not familiar with the invention would not necessarily have turned to ObjectSpace technology for help in finding a solution.
A prior approach investigated by Novell more than one year before the filing of the present appl
Andrew Chris
Nevarez Carlos A.
Courtenay III St. John
Dinsmore & Shohl LLP
Hoang Phuong
Novell Inc.
LandOfFree
Component architecture in a computer system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Component architecture in a computer system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Component architecture in a computer system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3082210