Electrical computers and digital processing systems: interprogra – Dynamic linking – late binding
Reexamination Certificate
1998-12-16
2004-09-28
An, Meng-Al T. (Department: 2126)
Electrical computers and digital processing systems: interprogra
Dynamic linking, late binding
C717S145000, C717S146000, C717S147000, C717S148000, C717S153000, C717S162000
Reexamination Certificate
active
06799320
ABSTRACT:
FIELD OF THE INVENTION
This invention relates generally to software component interfaces, and more specifically to providing binding options for software component interfaces.
BACKGROUND OF THE INVENTION
Software components are a technique used to improve software development productivity and program flexibility. Reusable software components are designed to apply the power and benefit of reusable, interchangeable parts from other industries to the field of software development. Software components have standard interfaces making them interchangeable and reusable. Examples of software components tend to be oriented toward user interface elements. They can be simple like familiar push buttons, text fields list boxes, scrollbars and dialogs, or they can be more complex, such as calculators and spreadsheets.
Microsoft's COM (Component Object Model) is an example of a software component development model. COM is a component environment commonly used by applications written in Microsoft's Visual Basic and Visual C++ programming languages. COM can generally be defined as a specification for a software development methodology and an Application Program Interface (API) that allows software components to communicate and interact with each other, and to be dynamically interchanged. A detailed description of COM methods and other aspects of COM are described in Dale Rogerson, “Inside COM,” 1997 (ISBN 1-57321-349-8) which is hereby incorporated by reference.
COM requires that software components, which are also referred to as COM objects, use certain standards and rules when defining the APIs that they expose to other components that they communicate with. The APIs they expose define the communication contract between components. An API that is exposed by a COM object is referred to as a COM interface. A programmer can use a published definition of a COM object and an interface it exposes to write programs that will use these objects by calling functions that are defined by the interface definition. The interfaces that are exposed by an object can be one of three different types: custom interfaces, dispatch interfaces and dual interfaces.
A custom interface requires the programmer calling the interface's methods to have the description of the interface at the time of the implementation. The calls made to the interface methods on custom interfaces are referred to as early bound calls. This is because the choice of which method to call occurs at the time the method is invoked. Interfaces of this type are derived from the common IUnknown interface definition.
A dispatch interface (dispinterface) hides the details of an interface implementation from the application programmer who is using it. Every method in a dispatch interface has an identification number that is referred to as a DISPID (dispatch identifier). The programmer prepares the code to call certain methods that are common for all dispatch interfaces, and passes the DISPID of the method to execute it. The programmer can also call other methods to convert method names that might be available in the program to DISPID values. The calls that are made to the methods on dispatch interfaces are referred to as late bound calls. This is because the choice of the particular method to call is made by the dispatch interface after the method has been invoked. A dispatch interface cannot be called using early bound calls. These interfaces are derived from the common IDispatch interface definition, which is derived from IUnknown interface definition.
A dual interface is an interface that is derived from a dispatch interface, but its methods can also be called using early bound calls.
COM components have the quality that when used within their intended environments, new or alternative components can be substituted for old components without requiring any changes to the application using the component. In addition, software components can be easily incorporated into new programs using software building tools, thereby freeing the developer from writing code to implement the functionality provided by the component.
The above described qualities provide significant advantages over other models for software development, however there are also several drawbacks.
First, a COM object exposes one or more interfaces with multiple methods on each. On larger components, the number of interfaces exposed and the number of methods on each interface may be overwhelming. This in turn results in a large number of test scenarios. The total number of test scenarios is directly related to the number of interfaces and methods, since each interface and method define different ways of using the component.
Second, as discussed above, an interface may be one of three types. The dual interfaces in particular require their methods to be tested both using the IDispatch interface approach and the custom interface approach. This causes the number of test scenarios to increase by at least a factor of two for dual interfaces.
Third, implementation of test cases requires different coding techniques for early bound and late bound interface calls. This can typically double the amount of test code to be written, with a corresponding increase in the time spent preparing and debugging the test cases.
For early bound cases in particular, there is also the overhead of rebuilding the code when the interface definition changes. Although typically an interface definition does not change once it is public, it can be modified during the implementation. With each change to the interface definition, all software modules that contain early bound calls to the interface must be rebuilt. This takes time, complicates the development process and requires the test group to have access to the detailed information about the interface definition at all times in order to be aware of any changes and rebuild the test code.
Finally, there is the problem of user education. COM can be a rather complicated area of software technology, and it takes a developer time to learn its details and intricacies. If the test scenarios are to be implemented using a conventional programming language, the developer has to be fluent using this programming language as well. This takes time and is an extra cost. In addition, there is a risk of having bugs in the test suite code, since it too is a complicated piece of code.
Therefore, there is a need for a component with a minimal number of easy to use interfaces that allow for the use of both early and late bound calls. In addition, the component needs to provide a choice of which type of call to be made at run-time. Finally, the applications using the component should not need to be recompiled and relinked and when an interface changes.
SUMMARY OF THE INVENTION
The above-mentioned shortcomings, disadvantages and problems are addressed by the present invention, which will be understood by reading and studying the following specification. The invention describes a component environment providing dispatch proxies and object proxies. In one embodiment of the invention, the computerized system includes an operating system supporting component interfaces. In addition, the system includes a first interface to a target component, with the first interface having an early bound method. The system further includes a second interface to a proxy component, with the second interface having a late bound method. Also included in the system is a dispatch proxy operative to invoke the early bound method of the first interface from an invocation of the late bound method of the second interface.
Thus, in one embodiment of the invention, a proxy component exposes a simple dual interface that contains methods and properties that can be accessed by its host application. An application can call these methods to create COM objects and ask for additional interface implementations from them. The methods are named after the actual COM library functions that are used in C/C++ programs, however those in the art will recognize that other alternative names are possible.
The p
Chronister Benjamin L.
Elvanoglu Ferhan
Lucas Terry L.
An Meng-Al T.
Anya Charles
Christensen O'Connor Johnson & Kindness PLLC
LandOfFree
Providing binding options for component interfaces does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Providing binding options for component interfaces, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Providing binding options for component interfaces will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3259588