Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
2000-09-29
2004-08-03
Courtenay, III, St. John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S203000
Reexamination Certificate
active
06772228
ABSTRACT:
COPYRIGHT NOTICE
Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates generally to software architectures involving a client interacting and interoperating with one or more servers. More particularly, the invention relates to increasing the functionality available to a client by a unique system and method for accessing and utilizing servers with a different functionality.
2. Background Information
An interesting trade-off has developed in certain areas of software application development. Two qualities that are desired in the development of most software applications, universality and changeability, are often at conflict.
Universality refers to development of applications that are portable to different software platforms, languages, and hardware and that may be operated on distributed networks using software that has already been developed by other software developers. Java, ActiveX, and Component Object Modeling (COM) are exemplary development tools that may be used to make applications more universal.
Universality may be better understood through a more detailed discussion of COM. COM has been developed to specify how objects interact and communicate within a single application, a distributed application or between applications (e.g., client/server applications) by defining a set of standard interfaces. Object interfaces are groupings of semantically related functions through which a client application accesses and utilizes the services of a server application. COM is a binary, network standard that allows software components to communicate with each other regardless of what machine they are running on, what operating system the machines are running (provided that it supports COM), and what language the components are written in (e.g., C, C++, Small Talk®, Ada, and Basic) provided they are capable of calling functions using pointers. COM further provides location transparency, meaning that software components may be written without knowledge of whether the other components are in-process DLLs, local EXEs, or located on another machine. Thus, COM has several desirable universal qualities. Further background information on COM is widely available, including the following references: (1)
Beginning ATL COM Programming
, Grimes, Stockton, Templeman and Reilly, Wrox Press, 1998 (ISBN 1-871000-11-1), and (2)
Beginning Visual
C++5, Chapter 22, Ivor Horton, Wrox Press, 1997 (ISBN 1-871000-08-1).
Paramount to COM is that a client does not need to know the internal workings of a published COM server (encapsulation) and that a COM server must always maintain complete backward compatibility to all existing client code. A strictly obeyed rule that once a COM object has been published (made available to the public) neither the functionality, unique identifiers, or interface of that COM object may be changed. Otherwise clients that were developed based on a reliance on the initial COM server would either not be operable (i.e., the applications may crash) or they would need recompilation every time one of the COM servers they access is changed. This would compromise much of the universality that COM provides. Accordingly, in COM new functionality has always been added by creating a new interface and unique identifier that is associated with the new functionality. This new functionality is not available to clients without modifying or recompiling the application. That is, universality is obtained at the expense of changeability.
Software should also be changeable, so that it may be adapted to changes in the real world or be improved. Accordingly, a software architecture that allows software or software objects to be changed easily and without recompilation is desirable.
Polymorphism is a widely used mechanism for implementing changeability in an object-oriented environment, however in COM the concept of an interface significantly limits polymorphism. Polymorphism allows an object to produce different results depending upon the type of object that invokes the object. For example, considering the base class shape, a polymorphic method for calculating area will produce different results if a circle and a square call the method.
COM provides containment and aggregation for achieving a limited form of polymorphism. One problem with both containment and aggregation is that objects and applications do not know how to interoperate with the new functionality provided through containment or aggregation. For example, the objects and applications may not know the Universally Unique Identifiers (UUIDs) associated with the new functionality. The UUIDs provide an unambiguous way to interoperate with a COM items or functionality without the possibility of name clashes between other items created by different people around the world. To interoperate, the object or application must know the exact path to import the interfaces from the COM items associated with the new functionality. Thus, changeability is significantly restricted.
Thus, prior art approaches for obtaining more universal software, such as COM, are based on creating an encapsulated, unchanging functionality that is accessed through an unchanging interface. This approach limits the way that software may be changed to be adapted to the real world and to be improved. Accordingly when COM is used for software application development, some of the advantages of changeability are sacrificed to gain universality. Similar limitations are expected in other software environments where universality is achieved by encapsulating functionality and interoperating through an interface or standard.
REFERENCES:
patent: 5812768 (1998-09-01), Page et al.
patent: 6141696 (2000-10-01), Goertzel et al.
patent: 6349342 (2002-02-01), Menges et al.
patent: 6618817 (2003-09-01), Armstrong
patent: 6631425 (2003-10-01), Helland et al.
Box, Don, “Essential COM”, Addison-Wesley, 1998, pp. 261-278.*
Dr. Gui on Components, COM and ATL; Printed Jul. 2000; http://msdn.microsoft.com/library/welcome/dsmsdn/msdn_drugion02098.htm.
Sara Williams and Charlie Kindel; “The Components Object Model: A Technical Overview”; Created ; Oct. 1994; Adapted from an article in Dr. Dobbs Journal; Dated Dec. 1994; http://msdn.microsoft.com/library/techart/msdn_comppr.htm.
Dr. Richard Grimes: “Beginning ATL COM Programming”; pp. 1-101; Published by Wrox Press Ltd.; ISBN 1-861000-11-1; Copyright 1998.
Blakely , Sokoloff, Taylor & Zafman LLP
Courtenay III St. John
Intel Corporation
LandOfFree
Achieving polymorphism in a COM software architecture or the... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Achieving polymorphism in a COM software architecture or the..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Achieving polymorphism in a COM software architecture or the... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3283286