Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-08-17
2002-08-27
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
06442620
ABSTRACT:
TECHNICAL FIELD
The present invention relates to system infrastructure and services that provide an object model or environment for hosting object-oriented component applications, and more particularly relates to extensibility of the object environment with added domain specific behaviors.
BACKGROUND OF THE INVENTION
Object models, such as the Microsoft Component Object Model (“COM”), define a standard structure of software objects that can be interconnected and collectively assembled into an application (which, being assembled from component objects, is herein referred to as a “component application”). The objects are hosted in an execution environment created by system services, such as the object execution environments provided by COM, as well as system services added by Microsoft Object Linking and Embedding (“OLE”), Microsoft Distributed Component Object Model (DCOM), and the Microsoft Transaction Server (“MTS”) systems. These systems expose services for use by component application objects in the form of application programming interfaces (“APIs”), system-provided objects and system-defined object interfaces.
In accordance with object-oriented programming principles, the component application is a collection of object classes which each model real world or abstract items by combining data to represent the item's properties with functions to represent the item's functionality. More specifically, an object is an instance of a programmer-defined type referred to as a class, which exhibits the characteristics of data encapsulation, polymorphism and inheritance. Data encapsulation refers to the combining of data (also referred to as properties of an object) with methods that operate on the data (also referred to as member functions of an object) into a unitary software component (i.e., the object), such that the object hides its internal composition, structure and operation and exposes its functionality to client programs that utilize the object only through one or more interfaces. An interface of the object is a group of semantically related member functions of the object. In other words, the client programs do not access the object's data directly, but must instead call functions on the object's interfaces to operate on the data.
Polymorphism refers to the ability to view (i.e., interact with) two similar objects through a common interface, thereby eliminating the need to differentiate between two objects. Inheritance refers to the derivation of different classes of objects from a base class, where the derived classes inherit the properties and characteristics of the base class.
The object execution environments of the above mentioned COM, OLE, DCOM, and MTS systems have several behaviors towards component application objects that depend on locality or like environment aspects (hereafter referred to as “domains”) of the component application objects. The domains of a component application object in these environments include physical location (e.g., machine and process), isolation domains (e.g., process, user/kernel, security, transactions, auditing), synchronization domains (e.g., apartments, activities), object lifetime and identity domains (e.g., persistence, just-in-time activation, assemblies, per-client global and shared state), and representation domains (e.g., unicode/ANSI, 16/32-bit, locale, native/automation, Java/COM). For example, the OLE object execution environment has behaviors for object persistence and local/remote transparency whose operation on an object depends on the object's location, e.g., machine and process. The MTS object execution environment has thread synchronization, automatic transactions, just-in-time object activation, declarative security and resource pooling behaviors that also are specific to an object's locality or other environment aspects that pertain to the object.
Although COM provides certain domain-specific behaviors in its object execution environment, COM lacks any structure or mechanism to extend the environment with new domain-specific behaviors. One problem is that such behaviors rely for their implementation on services that must automatically impose themselves into many interactions between objects, such as at object instantiation, upon passing an interface pointer, and during calls (function invocations and returns), preferably without relying on any programming or action on the part of the objects.
A further complication is that COM has services that provide processing during certain of the interactions, yet does not provide any mechanism to extend the service to also provide processing of new domain-specific behaviors. For example, COM has an object instantiation service (i.e., the “CoCreateInstance( )” API) that performs processing for certain system-provided environment behaviors at instantiation time, such as local/remote transparency.
Yet another complication is that certain inter-objects interactions do not involve any system-provided services in COM. For example, a call between two objects in a same process generally is made using a direct reference. Thus, no system service is invoked and afforded an opportunity to process domain-specific behaviors during these interactions.
The more recent MTS system extends the object execution environment of COM to include a number of additional domain-specific behaviors, including the before-mentioned thread synchronization, automatic transactions, just-in-time object activation, declarative security and resource pooling behaviors. However, the methods and mechanisms used in the MTS system to extend the COM object execution environment again fail to provide a general environment extensibility solution.
More specifically, one way in which the MTS system adds automatic services to extend the COM object execution environment is to provide a separate object instantiation service (the “IObjectContext::CreateInstance( )” function) that performs processing for the MTS domain-specific behaviors during object instantiation. This MTS object instantiation service is layered over the object instantiation service of COM (i.e., the “CoCreateInstance( )” API). In other words, after its domain-specific behavior processing, the MTS “IObjectContext::CreateInstance( )” function invokes the “CoCreateInstance( )” API to complete object instantiation processing (and domain-specific behaviors of COM).
This approach of layering separate new object instantiation services over that of the base system, however, has a number of drawbacks. First, in order to gain the full benefit of the domain-specific behavior, the new object instantiation service must be used in place of the base system's object instantiation service. This requires that the component application objects are rewritten to invoke the new service, or forgo the domain-specific behavior that the new service provides. In the MTS system for example, component application objects must be programmed to use the “IObjectContext::CreateInstance( )” function to create other component application objects. Otherwise, component application objects that are created via the “CoCreateInstance( )” API of the base COM system are not automatically placed in the same transaction as their creator, and do not have the full benefit of the MTS system's automatic transactions behavior. In many cases (e.g., for all previously developed and deployed legacy component applications), it may be impossible to rewrite the component applications to use new object instantiation services, which makes the new behaviors unattainable for such component applications.
Second, repeated use of the layering approach to add domain-specific behaviors to an environment can lead to competing layered services proliferating haphazardly. As a consequence, object developers may be forced to choose among the domain-specific behaviors of the object execution environment according to which of the competing layered services their component application objects are programmed to invoke. For example, suppose a new threading model behavior is provided in the CO
Gray Jan S.
Hill Richard D.
Johnson Eric W.
Kakivaya Gopal Krishna R.
Lyon James M.
Courtenay III St. John
Klarquist & Sparkman, LLP
Microsoft Corporation
LandOfFree
Environment extensibility and automatic services for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Environment extensibility and automatic services for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Environment extensibility and automatic services for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2910351