| Previous | Table of Contents | Next |
This problem is the reverse of exposing CORBA objects as Automation objects. It is best to solve this problem in a manner
similar to the approach for exposing CORBA objects as Automation objects.
19.9.1 Architectural Overview
We begin with ODL or type information for an Automation object, which implements one or more dispatch interfaces and whose
server application exposes a class factory for its COM class.
We then create a CORBA View object, which provides skeletal implementations of the operations of each of those interfaces.
The CORBA View object is in every way a legal CORBA object. It is not an Automation object. The skeleton is placed on the
machine where the real Automation object lives.
The CORBA View is not fully analogous to the Automation View, which as previously explained, is used to represent a CORBA
object as an Automation object. The Automation View has to reside on the client side because COM is not distributable. A copy
of the Automation View needs to be available on every client machine.
The CORBA View, however, can live in the real CORBA object’s space and can be represented on the client side by the CORBA
system’s stub because CORBA is distributable. Thus, only one copy of this View is required.
Note – Throughout this section, the term CORBA View is distinct from CORBA stubs and skeletons, COM proxies and stubs, and
Automation Views.
The CORBA View is an Automation client. Its implementations of the CORBA operations translate parameter types and delegate
to the corresponding methods of the real Automation object. When a CORBA client wishes to instantiate the real Automation
object, it instantiates the CORBA View.
Thus, from the point of view of the client, it is interacting with a CORBA object, which may be a remote object. CORBA handles
all of the interprocess communication and marshaling. No COM proxies or stubs are created.
Figure 19-6 The CORBA View: a CORBA Object, which is a Client of a COM Object