Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-11-18
2002-02-19
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000
Reexamination Certificate
active
06349343
ABSTRACT:
TECHNICAL FIELD
The present invention relates to object-oriented software systems and related methods for digital computers.
BACKGROUND ART
Using object-oriented software techniques, software applications for digital computers are created by combining software objects. To facilitate this process, object-oriented software systems typically provide an architecture specification, called the object model, which enables all objects developed to the specification to work together seamlessly in an application. Examples of object models would include the Object Management Group's Common Object Request Broker Architecture (CORBA), and Microsoft's Common Object Model (COM.) Such systems also typically provide software, called the object system, which implements the basic features provided for in the object model.
There are numerous object systems, some very general in nature such as Microsoft's Object Linking and Embedding (OLE) (which follows the COM object model), or IBM's Distributed System Object Model (DSOM), and Iona's ORBIX, (which both follow the CORBA object model). See for example: the OLE 2 Programmers Reference, Volume 1 and 2, Microsoft Press, 1994; the IBM SOMobjects Developer Toolkit V2.0, Programmers Reference Manual, 1993; Iona ORBIX, Advanced Programmers Guide, 1994; and The Common Object Request Broker: Architecture and Specification Ch. 6., OMG, 1991; these references are hereby incorporated herein by reference.
Other object systems are designed to provide specific functionality, for example, in areas such as groupware or relational database—e.g. Lotus Notes. Still other object systems are specific to particular to applications—e.g. Novell's AppWare Bus, Hewlett Packard's Broadcast Message Server, and Microsoft Visual Basic's VBX object mechanism. See for example: the Lotus Notes Programmers Reference Manual, 1993; the Novell Visual AppBuilder Programmers Reference Manual, 1994; the Hewlett Packard Softbench BMS, Programmers Reference Manual, 1992; Microsoft Visual Basic 3.0 Professional Features Book 1, Control Development Guide, 1993; these references are also hereby incorporated herein by reference.
In creating a software application it is desirable to combine objects from various object systems, because different object systems are best suited to different tasks, and because the best solution is usually built from the best parts (i.e. objects.) However, objects from various object systems don't naturally work together for a number of reasons.
Object systems are rendered incompatible due to differences in the means by which objects are created, methods are called and properties are set in each object system, including differences in the fundamental mechanisms used as well differences in low-level calling conventions such as the physical layout of types and classes. For example at the fundamental level, some object systems, such as COM, use direct C++ calling mechanisms. Others such as DSOM pre-process source code so that in place of a direct call, a function from the object system is called which, in turn, returns a pointer to the real method. This pointer is dereferenced to actually call the method. Still other object systems such as OLE Automation provide specialized functions developers must use to call methods (this is often referred to as a Dynamic Invocation Interface or DII). These functions take the method to be called as an argument, as well as the method's arguments (usually packed into a particular format), and they call the method for the developer. There are numerous other broad differences and variants in fundamental calling mechanisms. Each of these fundamental mechanisms also differ in detail. For example, CORBA requires an environment pointer argument (and has an optional context argument), while other object systems do not.
In addition to the vast differences in fundamental calling mechanisms, there are many differences in low-level calling conventions, sometimes referred to as procedure calling conventions. For example, different object systems handle the return value from methods differently when the type of the return value is a float or a structure. In one case the value may be returned on the processor stack, while in another the value may be placed in a register. Thus, using the return value of a method from a different object system would result in an error. Other examples of differences in procedure calling conventions would include how structures are packed into memory, and how arguments are placed on the stack.
Various object systems also support various types which may not be compatible with other object systems. Simple examples of types include language types such as integers, floats, etc. More complex language types include arrays, strings, and objects. There are also semantic types such as “variable types” like the CORBA Any, and the COM VARIANT. Semantic types differ from language types in that they have a particular semantic meaning to the system. While certain semantic types may conceptually mean the same thing among various object systems, their corresponding language representation and implementation may be entirely different. A common example is strings. In COM, strings are represented using a “BSTR” (a non-NULL terminated string which contains length information), while in CORBA, strings are the traditional C language byte array (NULL terminated with no length information). As a result, a COM object couldn't pass a BSTR to a CORBA object because any functions that operate on strings, such as copying and comparison, used in the CORBA object would fail. Likewise, while “variable types” such as the CORBA Any and the COM VARIANT “mean” the same thing, they aren't compatible.
In addition, object systems have various rules about lifecycle management which may be incompatible. The term lifecycle management refers to the process required when creating, storing, and deleting objects. For example, COM requires developers to perform reference counting so objects can be automatically deleted. Relational databases have much more sophisticated lifecycle management, while CORBA has only very simple lifecycle management with no reference counting.
The above issue of lifecycle management is challenging because often, objects are passed as arguments to methods. Consider the case where an object in one object system calls a method of an object in a foreign object system and passes an object (from its object system) in as an argument to the method. Since the foreign object system only understands its own objects, the object argument must be dynamically converted to a corresponding object in the foreign object system. In other words, a new object must be created in the foreign object system to match the original object passed in as an argument. All such dynamic lifecycle management—object creation, with its corresponding object destruction—must be handled properly if object system interoperability is to work.
Another aspect of object system interoperability is differences in exception and error handling among object systems. Errors or exceptions encountered within the code for an object typically must also be dealt with in the object which called the code. If the two objects are from different object systems, and the error handling mechanisms are incompatible, software failure may result.
Various object systems provide different ways to dynamically query for information about objects. This functionality is required for object systems that provide a general macro script recording facility as well as for object systems that provide distributed computing capabilities. See for example Ch. 1-3 of Microsoft's OLE 2 Programmers Reference Volume 2, Apple's Inside Macintosh: Interapplication Communication Ch. 8 (hereby incorporated herein by reference), or the Object Management Group's The Common Object Request Broker: Architecture and Specification Ch. 6. Thus, incompatibilities in the mechanisms to query for information about objects results in significant restrictions
Foody Daniel M.
Foody Michael A.
Courtenay III St. John
Visual Edge Software Limited
LandOfFree
System and method 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 System and method for providing interoperability among..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for providing interoperability among... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2947131