Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1996-11-20
2001-04-17
Oberley, Alvin E. (Department: 2755)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06219717
ABSTRACT:
BACKGROUND OF THE INVENTION
This invention relates to a method and apparatus for transparent invocation of object functionality, and more specifically, to a method and apparatus for initiation of the functions provided by an object's methods without specific knowledge of the identity, address, name or existence of the object.
DESCRIPTION OF RELATED ART
In recent years, programmers have developed a technology for building computer application programs out of building blocks called objects. Objects are involved in an application's activity by means of messages. In other words, to invoke the functions of a target object, a message is sent to the target, and the target object's functionality is invoked in response to the message.
As is well known in the art, objects of one type are defined by their attributes and methods. More specifically, attributes define properties or characteristics that can differ between objects of the same type, and methods define the functional behaviors of all objects of the same type.
All objects of the same type behave essentially in the same manner because they all share the same methods, but each object has its own instances of attributes and one object of a type may differ from another object of the same type by the attributes' actual values, i.e. by their contents.
To use an example, color may be an attribute of the objects of a given type. Each object of the type would have a color attribute, but the value of the color attribute may differ from one object to another object of the type. The behavior, or way the objects change color, is controlled by the method. Thus, for example, each object of this type may change from one color to another color in the same way.
Objects may be implemented in memory areas, screen images, disk files and other ways known in the art. Methods may be implemented in programs, scripts, functions and other ways known in the art.
As mentioned above, objects respond to messages. A message may be sent to request services of an object or to notify an object of events. For clarity, the source of a message, e.g., a program, a script or a procedure, where the message is originated, may be referred to as the sender, and the object which executes application functionality in response to a message may be referred to as the receiver.
Technically, a receiver may be comprised of more than one object, i.e. it can be a compound object. Common examples of such compound objects would include a window (object) with buttons (objects) on it, or a window (object) with message boxes (objects) which it may open during execution of its functionality, or a sheet (object) with a toolbar (object). A group of objects is considered a single component, i.e. a compound object, when the group: (i) is incorporated in an application as a whole, (ii) is created and destroyed in a single operation, and (iii) handles its internal composition and structure by itself.
The method by which a receiver responds to a message may be hidden from the sender; a method so hidden from the sender is known as an encapsulated method. Encapsulation of the method is desirable because the encapsulated method can be modified without needing to modify the sender.
An encapsulated method provides senders with its interface, i.e. messages to which this method responds. Only interfaces of encapsulated methods are open and known to senders. A set of interfaces of all methods of a particular receiver is referred to as the receiver's interface.
It is also well known, after composing a message, that a sender sends the message for a particular receiver. Thus, the sender must know the identity of the receiver. In other words, two components need to be specified for an object's functionality to be invoked: a receiver identity, which is an identifier for the particular receiver of the particular type; and the message, which may include a specific function request and the function's execution parameters. There are many known ways to define identity of a receiver, typically it is represented by a pointer or handle, i.e., a physical or logical address of the receiver.
Since receivers are created and destroyed dynamically during an application's execution, the identity of a receiver is usually determined at run time. Thus, to permit senders to become “acquainted” with receivers, a run time identification mechanism is required. Such a run time mechanism complicates the structure and function of senders and can require significant system resources, which makes development and maintenance cumbersome. Some examples of the run time identification mechanisms that are used to acquaint receivers include: storing receiver's identity using a global variable accessible throughout an entire application; and passing a receiver's identity as a parameter during the sender's initial invocation.
Thus, while conventional messaging systems allow for the implementation of methods that respond to messages from unknown senders, the sender is still required to definitively identify a receiver when sending a message. The limitations of this requirement have been referred to in the literature as the acquaintance problem. See, for example,
Directions in Object-Oriented Research
, D. Tsichritzis, O. Nierstrasz, and
Object
-
Oriented Concepts, Databases, and Applications
, W. Kim and F. Lochovsky, ACM Press, New York, 1989, pp. 523-536, both incorporated herein by reference. These limitations are a major drawback of conventional messaging and pose several substantial difficulties for application development and maintenance.
The acquaintance problem, often results in otherwise unnecessary modification to senders. For example, it is well known that when application architecture changes senders often need to be modified to reflect a change in the identity of a receiver. This is often true even if the methods and interface of the receiver stay the same. This problem may be caused, for example, if the order of object creation in an application is changed, or if the application architecture is changed to permit multiple objects of the same type.
In conventional systems it is often the case that a sender's implementation can depend upon the way messages are associated with receivers. In such a case, the sender may need to be modified when the receiver associated with a message is changed, even if the message stays the same. This problem may arise where a receiver of a different type is used to replace the original receiver. It may also occur where the receiver's interface is split between several receivers with narrower functionality or where the interfaces of several receivers are combined.
It is a common practice among programmers of ordinary skill in the art to replace an original receiver with a descendant having, for example, extended or specialized functionality. This may require that the sender be modified even though the sender does not take advantage of the extended functionality. This may result from using global variables which are automatically defined by an underlying system, in an effort to ease object identification for various types of objects.
Also due to the acquaintance problem, otherwise unnecessary modifications are also required when a sender is migrated to a different application context where receivers providing the same services are identified differently or have split, combined or rearranged interfaces.
A number of different solutions to the acquaintance problem have been proposed.
Dynamic adaptation is one proposed solution to the acquaintance problem. Dynamic adaptation systems are disclosed in
Adapting Object-Communication Methods Dynamically
, Yoshinori Kishimoto, Nobuto Kotaka, Shinichi Honiden, IEEE Software, Vol. 12, No. 3, May 1995, pp. 65-74, incorporated herein by reference.
A dynamic adaptation system caches specifications of the methods for the object types. In a dynamic adaptation system, when a sender migrates into a different environment and issues a message requesting the services of another object, the specifications of
Filkovsky Genady
Margulis Yuriv
Sawyer Kevin
Courtenay III St. John
Hopgood, Calimafde, Judlowe & Mondolino LLP
Merrill Lynch & Co. Inc.
Oberley Alvin E.
LandOfFree
Method and apparatus for implementing object transparent... 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 apparatus for implementing object transparent..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for implementing object transparent... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2544718