HK1171841B - Protected and virtual interfaces for com aggregation - Google Patents

Description

Protected and virtual interface for COM aggregation

Technical Field

The invention relates to protected and virtual interfaces for COM aggregation.

Background

An "object" in an object-oriented programming language is an encapsulated module of code and related data (called methods and properties of the object) that can be accessed by clients through interfaces that access well-defined and controlled connection points. A collection of objects may be created to perform the functions required in a computer application.

The Component Object Model (COM) is a binary interface standard for software components to implement communication and dynamic object creation in any programming language that supports it. The term COM is often used in the software development world to cover OLE, OLE automation,COM + and general terms for DCOM technology. COM provides a language neutral way of implementing objects so that the objects can be used in an environment different from the environment in which the objects were created.

One mechanism for implementing object reuse in COM is containment delegation. A containment delegation is a mechanism in which one object (the "outside" object) uses the functionality of another object (the "inside" object) to provide an interface implementation to a client of the outside object. The outer object "contains" the inner object. The foreign object exposes the interface to the client, but the implementation of some of these interface properties and methods are explicitly delegated to the methods of the foreign object. The containment of the outer object may be achieved by the outer object creating an inner object for its use; using its pointer to the inner object, a call to a method in the outer object results in a call to a method in the inner object.

COM aggregation is an extension of the hosting delegation of COM objects where external objects expose interfaces from internal objects as if the interfaces were implemented on the external objects themselves. That is, when a client of an external object requests an interface, if the external object does not have an implementation of the interface, it forwards the request to the internal object. If the internal object returns to the interface, the external object's client then makes method and property calls directly to the internal object. Note that the inner object itself may be the outer object of the third object, and the interface request may be similarly forwarded. The outermost object is referred to as the "control" object. If the client is interacting with an internal object and requesting a new interface, the internal object forwards the request to the control object so that the external object has an opportunity to answer the request before the internal object. This aggregation algorithm may be useful when an exo-object delegates all calls to one of its interfaces to the same interface in an intra-object. In this case, COM aggregation may avoid additional implementation overhead in the outer objects.

Disclosure of Invention

COM aggregation does not define the schema of the outer objects to have protected access to certain inner object interfaces. For example, an inner object may have an interface that it wishes to expose to an outer object but not to a client that controls the object. COM aggregation does not define the schema of an inner object to allow some of its method and property implementations to be overridden by an outer object. For example, an inner object may have a method for which the inner object wishes to give an outer object the ability to provide alternative behavior to that of the method.

The external COM object may be provided access to protected functionality in the internal COM object that is not exposed to the client controlling the object. In one approach, the internal COM object provides the protected interface to the external COM object by providing the external object with a new "protected" internal interface that is separate from the standard internal interface that the external object maintains in the COM aggregate. As with all interfaces in COM, the protected internal interface may be used to request other interfaces. However, the standard internal interface that the external object receives from the internal object can only be used to request an unprotected ("public") interface, and the protected internal interface can be used to request a protected interface. When an external object delegates an interface request from a client of the control object to an internal object, the delegated interface request is sent only to the standard internal interface, and thus the client of the control object is prevented from accessing the protected interface. When the external object wishes to access the protected functionality, the external object requests the protected interface from the protected internal interface. In an alternative approach, the internal objects provide a single interface to the external objects as in standard COM aggregation, which is an internal interface. Only requests for the public interface can be made from the internal interface, and when the external object delegates an interface request from the client of the control object, it requests the public interface. But the internal interface may also be used to request the protected interface of the internal object, which the external object uses to invoke the protected interface. The client of the control object is not given access to the protected interface.

An external COM object may override a behavior in an internal COM object. The inner object makes this capability possible by defining a new overlay interface for this purpose and requesting the new overlay interface from the control object. This allows the control object or some other external object to provide the requested interface. If no external object implements the overlay interface, the interface request is instead delegated to the original internal object, so that the internal object eventually calls its own implementation. If the inner object is intended to make the coverable interface common (available to the client controlling the object), then a standard interface request is made. That is, when an intra-object (or any other code) wishes to invoke an overrideable method, it requests the interface from the control object using a standard interface request. The inner object may also have the coverable interface protected as described in the previous paragraph. In this case, in one approach, the external COM object provides a protected coverable internal interface to the internal object. When an intra-object requests an overlay interface from a control object, the request is sent on the protected overlay-capable intra-interface. When an external object delegates the interface request to an internal object, it does so using the internal object's protected internal interface, as described in the first approach of the previous paragraph. In an alternative approach, the outer object provides a single interface to the inner object as in the standard COM aggregation approach, which is the inner interface. From which a request may be made for a public or protected interface. When an inner object wishes to invoke an overrideable method, it makes a request to the control object over the internal interface. When an external object delegates the interface request to an internal object, it again uses the internal interface to do so, as described in the second approach of the previous paragraph.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Drawings

In the drawings:

FIG. 1a illustrates an example of a system 100 for creating protected and/or virtual interfaces for COM aggregation in accordance with aspects of the subject matter disclosed herein;

FIG. 1b shows an illustration of an example of a model for creating protected and/or virtual interfaces for COM aggregation in accordance with aspects of the subject matter disclosed herein;

FIG. 2 is a flow diagram of an example of a method 200 for creating COM aggregated protected and/or virtual interfaces on a computer in accordance with aspects of the subject matter disclosed herein;

FIG. 3 is a block diagram of an example of a computing environment in accordance with aspects of the subject matter disclosed herein; and

FIG. 4 is a block diagram of an example of an integrated development environment in accordance with aspects of the subject matter disclosed herein.

Detailed Description

Overview

COM objects implement the IUnknown interface and other interfaces that implement the IUnknown interface method. The IUnknown interface shows three methods: QueryInterface, AddRef, and Release. QueryInterface is used to obtain a pointer to another interface if an identifier calls a GUID (globally unique identifier) that identifies the desired interface. AddRef is used by one or more clients (e.g., applications) to indicate that a COM object is being referenced. AddRef is incremented with each reference made so that COM objects are not removed prematurely. Release is used by the client to indicate that the client has completed using the COM object. Unreferenced COM objects can be safely removed. The aggregation of COM objects uses a special "untrusted" implementation of IUnknown on an intra-object that forwards a QueryInterface request for an unknown interface to its own intra-object (if any). Additionally, the IUnknown method for any other interface on the internal object is delegated to the IUnknown method for the external "control" object. Conventional COM aggregation allows objects to create internal objects but does not describe the way an external (aggregator) COM object has privileged access to protected functionality in the internal (aggregated) COM object. COM aggregation also does not describe the way in which an external object overlays the behavior of an object within (overrides).

According to aspects of the subject matter disclosed herein, mechanisms are provided that allow an internal COM object to provide an external COM object with dedicated access to a subset of functions of the internal COM object. The external COM object may receive a dedicated callback from the internal COM object. External COM objects can provide additional functionality to calling applications by defining new interfaces and runtime classes.

Protected and virtual interface for COM aggregation

In some programming languages, including C + +, the base class may define protected and virtual members. The derived class may call the protected member and may override the virtual member. This is illustrated in the following code fragment:

in the C + + program code copied above, there is a protected (protected) virtual method called OnClick on a class named CButton. When the implementation of the Cbutton class somehow determines that it has been "pressed," it calls the OnClick method. Since CButton's OnClick method is virtual and is overridden by the OnClick method in CMyButton, the OnClick method, which is actually CMyButton, is called. "in these method examples indicates that certain other program instructions may or may not be included here. CMyButton:: OnClick can execute its desired code, including calling CButton:: OnClick method that may have been called, provided it is not covered by CMyButton. Those using C + + often refer to these two capabilities as "able to override virtual methods" and "able to call up to the base". Also shown in this example are two protected methods for CButton, OnClick and SetButtonContent. Since these methods have protected access, they are typically only callable by code in the CButton class or by code in a derived class such as CMyButton.

If this example is implemented using COM aggregation, there is currently no description of the way in which the interface to a CButton object (e.g., the IButton interface) keeps the SetButtonContent method protected, and there is no way in which the interface to a CMyButton object (e.g., the interface that implements the IMyButton interface) overrides the OnClick method of CButton. According to aspects of the subject matter disclosed herein, a new COM interface is provided that enables protected methods and virtual methods in aggregated COM objects. It will be appreciated that in the example provided, the virtual method is also a protected method, but it will be appreciated that the virtual method may also be an unprotected method.

In this example, the COM implementation of these objects may have the following interfaces:

assume that CButton implements two interfaces: unprotected interfaces IButton and protected interfaces IButton protected, and a public or protected interface IButton override. CButton may be implemented to call IButtonOverride when instructed. IButtonOverride may also be implemented by CMyButton. According to aspects of the subject matter disclosed herein, the above implementations may be accomplished by creating a new interface by creating a new object or by creating a new interface that is simply an extension of the IUknown interface.

Fig. 1a illustrates an example of a system 100 for creating protected and/or virtual interfaces for COM aggregation in accordance with aspects of the subject matter disclosed herein. All or portions of system 100 may reside on one or more computers such as the computers described below with reference to fig. 3. All or part of system 100 may reside on one or more software development computers, such as the computers described below with reference to FIG. 4. The system 100, or portions thereof, may comprise a portion of an Integrated Development Environment (IDE) such as those described and illustrated below with reference to fig. 4. Alternatively, system 100 may exist outside the IDE. The system 100 or portions thereof may be provided as a stand-alone system or as a plug-in or add-on.

System 100 may include one or more computers 102, computer 102 including a processor (such as processor 142), a memory (such as memory 144), and one or more modules (such as module 106) for creating protected and/or virtual interfaces for COM aggregation, and the like. Other components known in the art may also be included but are not shown here. It will be appreciated that one or more modules (e.g., modules 106, etc.) that implement the protected and/or virtual interfaces of COM aggregation may be loaded into memory 144 to enable one or more processors, such as processor 142, to perform actions attributed to the one or more modules used to create the protected and/or virtual interfaces of COM aggregation.

In operation, a developer enters source code 108 into editor 116, module 106 acts on source code 108 to create one or more COM objects (such as COM object 114) and/or one or more COM object interfaces (such as COM object interface 112), as described more fully below. Module 106, etc. may be a module of compiler 110, or may be a plug-in, or may be separate from compiler 110. Modules 106, etc. and/or compiler 110 may generate one or more COM objects (such as COM object 114) and/or one or more COM object interfaces (such as COM object interface 112). During runtime, COM objects and interfaces as described below may be dynamically generated.

FIG. 1b illustrates an object separation approach for creating protected and/or virtual interfaces for COM aggregation. In fig. 1B, COM object a 154 (the innermost object) is aggregated by COM object B152. COM object B152 hosts or aggregates COM object a 154, and COM object B152 is hosted or aggregated by COM object C150. While three COM objects are shown in fig. 1b, it will be appreciated that the subject matter described herein applies equally to two COM objects or more than three COM objects. COM object C150 is an external object to COM object B152 and COM object B152 is an external object to COM object a 154. Thus, the COM object B152 is both an external object and an internal object. COM object a 154 is an internal object of COM object B152. COM object B is an internal object of COM object C150. COM object C150 is a control object. COM object C150 exposes interface ICOMObjectCInterface 166 and controls IUnknown interface icomobjectciunswninterface 168. The COM object B152 exposes a trusted interface icomobjectbinface 174 and an untrusted IUnknown interface ICOMObjectBNDIUnknownInterface 170. The COM object a 154 exposes a trusted interface icomobjectaininterface 176 and an untrusted IUnknown interface ICOMObjectANDIUnknownInterface 172. COM object C150 is the outermost object. The outermost object passes itself as the control unknown interface and the control internal interface.

If, according to known COM aggregation capabilities, the calling application calls a QueryInterface method on an interface of COM object C150 (e.g., on icomobject knowninterface 168), icomobject bininterface 174 will be returned to the application. COM object C150 can call into COM object B152 using the untrusted IUnknown interface icomobinknown interface 170. This situation can occur because when the COM object C150 creates the COM object B152, the COM object C150 passes the control unknown object interface (icomobjectciunrwninterface 168) to the COM object B152. In response, the COM object B152 passes back to the COM object C150 the untrusted unknown interface icomobjectbndiuknown interface 170. Furthermore, if a calling application (a client that controls a COM object, COM object C150) calls a QueryInterface method on an interface implemented by COM object C150, COM object C150 will issue a call to COM object B152, and COM object B152 will issue a call to COM object a 154 to query the interface. The COM object a 154 may return, for example, the ICOMObjectAInterface176 to the COM object B152. The COM object B152 may then return the ICOMObjectAInterface176 to the COM object C150. This situation can occur because when COM object B152 creates COM object a 154, COM object B152 passes an unknown interface of control (icomobjectciunrwninterface 168) to COM object a 154. In response, the COM object a 154 passes the untrusted unknown interface icomobudandiunknowninterface 172 back to the COM object B152.

According to aspects of the subject matter disclosed herein, when an external COM object creates an internal COM object, the external COM object passes control internal objects to the internal COM object in addition to passing control unknown objects to the internal COM object. In response to receiving the control internal object, the internal COM object passes the internal object to the external COM object. The control internal object and the internal object may implement a protected interface and/or an overlay interface. If an object is created but not passed to control an internal object, the created object does not return an internal object.

For example, referring again to fig. 1B, when a COM object C150 creates a COM object B152, the COM object C150 passes a control internal interface, such as ICOMObjectAOverride180, IUnknown interface for COM object C internal objects 160, etc., to the COM object B152 in addition to passing a control unknown interface (e.g., icomobjectciukknowninterface 168) to the COM object B152. In response, the COM object B152 passes back to the COM object C150 an internal interface, such as ICOMObjectBOverride 186, for internal objects 162 within COM object B. Internal objects 162 within COM object B may implement protected and overlay interfaces such as icomobjectbpprotected 184 and/or ICOMObjectBOverride 182. It will be appreciated that the overlay interface may be protected or public. The common overlay interface may be implemented by having the overlay interface on a regular object rather than an internal object. For example, the common overlay interface may be placed on COM object B152 instead of internal object 162 within COM object B.

Using this object creation mode, an application calls the QueryInterface method of an external object against an overlay or protected interface to get any interface on the object will fail. For example, a QueryInterface method that calls ICOMObjectCInterface 166 for ICOMObjectBProtected 184 will fail. However, since the outer object has access to the inner object of the inner object, the outer object has access to the protected and/or overlay interface. For example, since COM object C150 has access to an internal object of COM object B152, namely COM object B internal object 162, COM object C150 has access to any protected and/or overlay interface of COM object B152. The COM object C150 has access to the internal objects of the COM object B152, i.e. the COM object B internal objects 162, because during the creation of the COM object B152, the COM object B152 passed its icomobjectbpprotected 184 interface to the COM object C150. Thus, COM object C150 can access any protected and/or overlay interface of COM object B152. In addition, each internal object has access to the outermost or controlling internal object.

For example, assume that COM object A154 (the innermost object) wants to access ICOMObjectAOverride. ICOMObjectAOverride may be implemented on COM object C150 and/or on COM object B152. COM object a 154 may call a QueryInterface on a control internal object implemented by COM object C (e.g., COM object C internal object 160). If the overlay method is implemented by a COM object C150, the ICOMObjectAOverride180 of the COM object C returns itself. If ICOMObjectAOverride is not implemented in COM object C, then the call to QueryInterface is delegated to an internal object within COM implemented by COM object B152, giving COM object B152 the opportunity to return its ICOMObjectBOverride 182, and so on. This is similarly true for the overlay interfaces icomobjectbootride 178 and icomobjectbootride 186 and protected interfaces (such as icomobjectbpprotected 184) of COM object B and the protected interface ICOMObjectAProtected 188 of internal objects 164 within COM object a.

In the interface separation approach, no separate object is created for the protected internal interface and/or no separate object is created for the overlay internal interface. Instead, according to aspects of the subject matter disclosed herein, a new extended IUnknown interface is created that can be used to access these interfaces:

when an intra-object is created, a controlling internal interface (e.g., IInteralInterface) may be passed to the intra-object, and an intra-internal interface (e.g., IInteralInterface) may be returned. If an object is created but not passed to control an internal interface (e.g., an IInteralInterface), then similarly, the IInteralInterface is not returned.

IInternalInterface QueryInternalInterface can be queried to obtain the protected interface of the object. If an external object is queried via its IInterlnterface:, QueryInternalInterface method to obtain an interface it does not support, it forwards the query request to the IInterlnterface of the internal object. A queryinterlnterface may be queried to obtain any interface, but a QueryInterface of an object may not be queried to obtain a protected interface. For example, QueryInterface and QueryInternalInterface of COM object C may be queried to obtain ICOMObjectC, but QueryInternalInterface may only be queried to obtain ICOMObjectBOverride. IInternalInterface, QueryInterface returns IUnknown's public interface.

Fig. 2 illustrates an example of a method 200 for creating protected and/or virtual interfaces for COM aggregation in accordance with aspects of the subject matter disclosed herein. The method described in FIG. 2 may be practiced by a system such as, but not limited to, that described in FIG. 1 a. Some of the acts described below may be optional. Some of the actions described below may be performed in a different sequence than described below.

At 202, a request to create an object is received. At 204, the outer object creates an inner object. At 206, the outer object passes control of the unknown interface to the inner object. At 208, the external object receives the non-trusted unknown interface returned from the internal object. At 212, the outer object passes control of the inner interface to the inner object. At 214, the outer object receives the inner internal interface back from the inner object.

Examples of suitable computing environments

In order to provide context for various aspects of the subject matter disclosed herein, FIG. 3 and the following discussion are intended to provide a brief, general description of a suitable computing environment 510 in which embodiments of the subject matter disclosed herein may be implemented. While the subject matter disclosed herein is described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other computing devices, those skilled in the art will recognize that portions of the subject matter disclosed herein also can be implemented in combination with other program modules and/or combinations of hardware and software. Generally, program modules include routines, programs, objects, physical artifacts, data structures, etc. that perform particular tasks or implement particular data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments. The computing environment 510 is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the subject matter disclosed herein.

With reference to FIG. 3, a computing device in the form of a computer 512 is depicted. The computer 512 may include a processing unit 514, a system memory 516, and a system bus 518. The processing unit 514 can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit 514. The system memory 516 may include volatile memory 520 and non-volatile memory 522. Non-volatile memory 522 may include Read Only Memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), or flash memory. Volatile memory 520 may include Random Access Memory (RAM), which may act as external cache memory. The system bus 518 couples system physical artifacts including the system memory 516 to the processing unit 514. The system bus 518 may be any of several types of bus structures including a memory bus, memory controller, peripheral bus, external bus, or local bus and may use any of a variety of available bus architectures.

Computer 512 typically includes a variety of computer readable media such as volatile and nonvolatile media, removable and non-removable media. Computer storage media may be implemented by any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other transitory or non-transitory medium which can be used to store the desired information and which can accessed by computer 512.

It will be appreciated that FIG. 3 describes software that can act as an intermediary between users and computer resources. The software may include an operating system 528, which may be stored on disk storage 524, may control object A (the innermost object) and allocate resources of the computer system 512. Disk storage 524 may be a hard disk drive connected to the system bus 518 through a non-removable memory interface such as interface 526. System applications 530 take advantage of the management of resources by operating system 528 through program modules 532 and program data 534 stored either in system memory 516 or on disk storage 524. It is to be appreciated that a computer can be implemented with various operating systems or combinations of operating systems.

A user may enter commands or information into the computer 512 through input device(s) 536. Input devices 536 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, and the like. These and other input devices connect to the processing unit 514 through the system bus 518 via interface port(s) 538. Interface port(s) 538 may represent a serial port, a parallel port, a Universal Serial Bus (USB), or the like. The output device 540 may use the same type of port as the input device. Output adapter 542 is provided to illustrate that there are some output devices 540 like monitors, speakers, and printers that require special adapters. Output adapters 542 include, but are not limited to, video and sound cards that provide a connection between the output device 540 and the system bus 518. Other devices and/or systems of devices, such as remote computer 544, may provide both input and output capabilities.

The computer 512 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 544. The remote computer 544 can be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 512, although only a memory storage device 546 has been illustrated in fig. 3. Remote computer(s) 544 may be logically connected via a communication connection 550. Network interface 548 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN), but may also include other networks. Communication connection(s) 550 refers to the hardware/software employed to connect the network interface 548 to the bus 518. Connection 550 may be internal or external to computer 512 and include internal and external technologies such as modems (telephone, cable, DSL and wireless) and ISDN adapters, ethernet cards and so on.

It will be appreciated that the network connections shown are examples only, and other means of establishing a communications link between the computers may be used. One of ordinary skill in the art can appreciate that a computer 512 or other client device can be deployed as part of a computer network. In this regard, the subject matter disclosed herein relates to any computer system having any number of memory or storage units and any number of applications and processes occurring across any number of storage units or volumes. Aspects of the subject matter disclosed herein may apply to an environment with server computers and client computers deployed in a network environment, having remote or local storage. Aspects of the subject matter disclosed herein may also apply to a standalone computing device, having programming language functionality, interpretation and execution capabilities.

FIG. 4 illustrates an Integrated Development Environment (IDE)600 and a common language runtime environment 602. The IDE 600 may allow a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug, or build programs, assemblies of programs, websites, web applications, and web services in a computer system. The software program may include source code (component 610) created in one or more source code languages (e.g., Visual basic, Visual J #, C + +, C #, J #, Java Script, APL, COBOL, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk, etc.). The IDE 600 may provide a native code development environment, or may provide managed code development running on a virtual machine, or may provide a combination thereof. The IDE 600 may provide a managed code development environment using the NET framework. An intermediate language component 650 may be created from the source code component 610 and the native code component 611 using a language specific source compiler 620, and the native code component 611 (e.g., machine executable instructions) may be created from the intermediate language component 650 using an intermediate language compiler 660 (e.g., a just-in-time (JIT) compiler) when executing the application. That is, when an IL application is executed, it is compiled while being executed into the appropriate machine language for the platform on which it is being executed, thereby enabling code to be portable across several platforms. Alternatively, in other embodiments, the program may be compiled into a native code machine language (not shown) suitable for its target platform.

A user may create and/or edit source code components via the user interface 640 and source code editor 651 in the IDE 600 according to known software programming techniques and the specific logical and syntactic rules associated with a particular source language. Thereafter, the source code component 610 can be compiled via a source compiler 620, whereby an intermediate language representation of the program, such as assembly 630, can be created. The assembly 630 can include an intermediate language component 650 and metadata 642.

The application design may be able to be verified before deployment.

The various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus disclosed herein, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing aspects of the subject matter disclosed herein. In the case of program code execution on programmable computers, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs that may utilize the creation and/or implementation of domain-specific programming models aspects, e.g., through the use of a data processing API or the like, may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

While the subject matter disclosed herein has been described in connection with the appended drawings, it is to be understood that modifications may be made to perform the same function in a different manner.

Claims (10)

1. A method for creating protected and virtual interfaces for COM aggregation, comprising:

creating an external COM object (150), the external COM object (150) aggregating internal COM objects (152);

creating the internal COM object (152);

passing a control unknown object (170) from the external COM object (150) to the internal COM object (152);

receiving, by the external COM object (150), a non-delegated unknown object (156) from the internal COM object (152);

passing a control internal COM object (160) from the external COM object (150) to the internal COM object (152);

returning an inner internal COM object (162) from the inner COM object (152) to the outer COM object (150); and

a request is received to create an interface (184) of the internal COM object (152), the interface (184) being inaccessible by a calling application but the interface (184) being accessible by the external COM object (150).

2. A method according to claim 1, wherein the internal COM object implements a protected interface, the protected interface comprising an interface that is not accessible by the calling application but is accessible by the external COM object.

3. A method according to claim 1, wherein the internal COM object defines an overlay interface, and wherein the internal COM object queries a controlling internal object of the overlay interface defined by the internal COM object.

4. A method according to claim 3, wherein an external internal COM object implements an interface accessible by the internal COM object that overrides the behavior of the internal COM object by providing its own behavior implementation.

5. A method according to claim 1, wherein an external internal COM object implements an interface accessible by the internal COM object that overrides the behavior of the internal COM object and also invokes entry into the internal COM object.

6. A method according to claim 1, wherein the external COM object uses the internal object to request a protected interface of the internal COM object.

7. A method according to claim 1, wherein the external COM object receives a protected interface of the internal COM object and uses the protected interface of the internal COM object to call a protected subset of functions of the internal COM object.

8. A method for creating protected and virtual interfaces for COM aggregation, comprising:

receiving a request to create an external COM object (202);

creating the external COM object, the external COM object aggregating internal COM objects (204);

creating the internal COM object (205);

passing an extension to an internal IUnknown interface from the external COM object to the internal COM object (208); and

an extension to an internal IUnknown interface is received by the external COM object from the internal COM object (208).

9. A method according to claim 8, wherein the internal COM object provides the external COM object with dedicated access to a subset of functions of the internal COM object, wherein the subset of functions includes protected content.

10. A system for creating protected and virtual interfaces for COM aggregation, comprising:

means for receiving a request to create an external COM object;

means for creating the external COM object, the external COM object aggregating internal COM objects;

means for creating the internal COM object;

means for passing an extension to an internal IUnknown interface from the external COM object to the internal COM object; and

means for receiving, by the external COM object, an extension to an internal IUnknown interface from the internal COM object.