internet
TRANSCRIPT
COMPARISON AND BRIDGE BETWEEN CORBA AND DCOM
Wenjie Lin
Directed by Dr. W. Homer Carlisle
Nov. 18, 1998
What’s CORBA and DCOM ?
CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Component Object Model) are two major standards for distributed object computing.
CORBA was proposed by the Object Management Group (a consortium of 700+ companies); while DCOM was developed and advocated by Microsoft alone.
Problems
• CORBA and DCOM both provide an infrastructure for defining, constructing, deploying, accessing objects in an distributed environment, but in different ways.
• Incompatibility: Objects residing in these two systems can not communicate directly.
• A dilemma for enterprises
Questions
• What differences are there between CORBA and DCOM ?
• Can these two systems work together?
• How can these two systems work together?
Agenda
• CORBA Overview
• COM/DCOM Overview
• A Comparison between CORBA and DCOM
• CORBA/DCOM Bridge
CORBA Overview
Object Request Broker
Application Objects
CORBAServices
Naming PersistenceLife cycleTrading Event Transaction ConcurrencySecurity
Relationship Query Licensing Properties ExternalizationEvent Time
CORBAFacilitiesVertical Facilities
Horizontal Facilities
UserInterface
InformationManagement
SystemsManagement
TaskManagement
CORBA Architecture
CORBA IDL
• The services that a CORBA object can provide are expressed in an interface with a set of methods
• The interface servers as a binding contract between clients and servers.
• CORBA uses OMG Interface Definition Language• Clients and Servers written in different languages
communicate through a mapping of IDL to these languages.
Client
Client Stub Code
Object Request Broker
ObjectSkeleton Code
Object
Function Call
Client Host Server Host
CORBA Static Method Invocation
Object Request Broker
ObjectSkeleton Code
Function Call
Client Host Server Host
DynamicInvocationInterface
Client Object
CORBA Dynamic Method Invocation
module AddressBook {
struct Address { string street; string city; string state; long zip; };
struct Entry { string name; Address address; long number; };
interface BookKeeper {
readonly attribute long numberOfEntries;
boolean addEntry(in string name, in Address addr, in longnumber); boolean removeEntry(in string name); long lookupNumber(in string name); Address lookupAddress(in string name); boolean changeNumber(in string name, in long new_number); boolean changeAddress(in string name, in Address new_address);
};};
ORB
Clients Object Implementations
Object Request Broker
Interface Repository Implementation Repository
DynamicInvocationInterface
Static IDLStubs
ORBInterface
ObjectAdapters
Static IDLSkeleton
DynamicSkeletonInterfaces
CORBA Application Development
• Define the object’s interface in OMG’s IDL
• Compile the IDL
• Implement the server (providing implementation code for the interface it supports
• Compile and register the server object
• Create and compile the client program
Approaches to Server Implementation
• Inheritance Approach: The IDL compiler generates an abstract base class for server implementation. A server implementation class must extend this abstract class. The server application can simply instantiate objects of the implementation class
• The TIE approach: Client invocations are routed to the TIE object and then the TIE object delegates the call to implementation object
Server Implementation - TIE approach
Client Operation Invocations
Client Operation Invocations
TIEObject
TIEObject
IDLInterface
ImplementationObject
ImplementationObject
_tie_BookKepper.java
BookKeeperImplementation.java
The CORBA Implementation of the Sample Application - AddressBook
• The application was implemented using OrbixWeb3.0, a product of IONA technology
• The IDL file of the application defines two structures, one attributes and six operations for adding, changing, deleting an entry as well as lookup entry by name
• The server is implemented using the Inheritance approach
• Two clients were created. One was written in plain Java application, and the other was written in Java applet
module AddressBook {
struct Address { string street; string city; string state; long zip; };
struct Entry { string name; Address address; long number; };
interface BookKeeper {
readonly attribute long numberOfEntries;
boolean addEntry(in string name, in Address addr, in longnumber); boolean removeEntry(in string name); long lookupNumber(in string name); Address lookupAddress(in string name); boolean changeNumber(in string name, in long new_number); boolean changeAddress(in string name, in Address new_address);
};};
COM/DCOM Overview
COM Basics • Access to an object only through interfaces• A COM interface is structured as a table of
pointer to functions (virtual function table)• COM defines a standard way to layout virtual
function tables (vtables) in memory and to call functions through the vtables
• COM defines a base interface (IUnknown) to provide lifetime management and query objects for functionality
• COM defines a mechanism to identify objects and their interfaces uniquely worldwide
Pointer tointerface
FuncA
FuncB
…
FuncC
pFuncA
pFuncB
…
pFuncC
vtable Object withmember functions
COM Interface Pointer and vtable
IUnknown Interface
Interface IUnknown{ HRESULT QueryInterface(IID& iid, void **ppv); ULONG AddRef(void); ULONG Release(void);}
COMClient
COMClient
COMLibrary
COMLibrary
SystemRegistry
SystemRegistry
ServerBinary Code
ServerBinary Code
CLSID
CLSID
Server binary code
Inte
rfac
e po
inte
r
Creation of COM Objects
HRESULT CoCreateInstance { REFCLSID clsid, LPUNKNOWN *pUnkOuter, DWORD dwClsCtx, REFIID riid, LPVOID *ppv, };
COM Library Function for Object Creation
DCOM - COM With a Longer Wire
Client ComponentProxy Object
DCE RPC
Protocol Stack
Stub
DCOM network-protocol
SecurityProvider
DCE RPC
Protocol Stack
SecurityProvider
SCM SCM
OLE32
"CoCreateInstance"
(Remote)Activation
"CoCreateInstance"
DCOM Architecture
API function for Creatinga COM object on Remote
MachinesHRESULT CoCreateInstanceEx ( REFCLSID clsid, LPUNKNOWN *pUnkOuter, DWORD dwClsCtx, COSERVERINFO * pServerInfo, ULONG cmq, MULTI_QI rgmq[]);
DCOM Application Development
• Define the object’s interface using MIDL
• Compile the IDL file to generate proxy/stub and other supporting files
• Implement the server by providing implementation code for the interface it supports
• Compile the server implementation code and register the server executable with the system registry
• Compile the proxy/stub code to generate the proxy/stub DLL and register it with system registry
• Create and compile the client program
The DCOM Implementation of the
Sample Application • The MIDL file for this application defines an interface
named IBookKeeper which inherits from IUnknown, a library named AddressBookLib, and implementation class named CBookKeeper that will implement the IBookKeeper interface
• The MIDL file was compiled using the MIDL compiler that comes with Visual C++
• The server implementation class implements methods that the interface IBookKeeper supports, the methods of IUnknown, and some methods of the class factory
• The client program was written in Visual C++
A Comparison between CORBA and DCOM
Object Model
• Both distinct interface from implementation, and clients invoke methods through a reference
• CORBA clients access object through object reference and DCOM through interface pointer
• Both CORBA and DCOM interfaces are language independent
• CORBA achieves it through language mapping, DCOM does it though binary standard
CORBA and DCOM Interface
• Naming systems: CORBA uses a mechanism like Java Package (class name + module name), DCOM uses UUIDs
• Association of class and interface(s) it supports: CORBA follows a standard model and specified in the interface’s implementation class; in DCOM, it is specified in the IDL file, and the association is purely arbitrary
• CORBA IDL supports user-defined exception types, DCOM does not.
• CORBA supports multiple inheritance of other interfaces at the IDL level, but DCOM does not
Client/Server Architecture
• Both provides RPC-style client/server communication(client - Client Stub - network - server stub - server)
• CORBA does not specify what wire protocol for the communication within same ORBs, but specifies TCP-based protocol (IIOP) for inter-ORB communication; DCOM can use any protocols that used in DCE RPC
Server Implementation and Registration
• In CORBA, the implementation class needs only to implement the interface it supports
• In DCOM, the implementation class needs, additionally, to provide implementation for the IUnKnown interface and IClassfFactory interface if COgetClassObject() is used to object creation
• Both CORBA and DCOM server need to be registered before clients can use its services. CORBA uses Implementation Repository, DCOM uses system registry.
Method Invocation
• Both CORBA and DCOM provide static and dynamic method invocations.
• No much differences in the way of static invocation• CORBA achieves the dynamic invocation through
the use of Interface Repository and Dynamic Invocation Interface (DII), there is no difference in object implementation for static or dynamic invocation; DCOM achieves the DI through Type Library and IDispatch interface, objects that supports DI must implements the IDispatch interface
Object Lifetime Management
• CORBA manages object lifetime through its Lifetime Service.
• DCOM manages object lifetime through counting methods provided in IUnknown interface
• CORBA specification does not attempt to track the number of clients communicating with a particular object; DCOM does
Security
• CORBA’s security is provided by CORBA’s Security Service. It defines three levels of security (from non-aware to full range). Different ORB products differ widely.
• DCOM uses NT mechanism as basis of its security control. Additional security service can be provided by adding Microsoft Transaction Server.
CORBA/DCOM Bridge
The Problems
• CORBA and DCOM have their own advantages and disadvantages (i.e. CORBA’s better platform independence and exception handling, DCOM’s better user interface)
• Relying on a single infrastructure can be risky since application systems are very dependent on their infrastructure
• Current application systems exist in many enterprises
The Solution is to make CORBA/DCOM
working together
How ?
COM/CORBA Interworking through Bridge
Object reference in B
Object Model A (client) Object Model B (Server)
Object reference in A
View of Target object
TargetObject
The Interworking Model
Bridge View Object
COM Interface
Automation Interface CORBA Object
DCOMObject
OrbixCOMet Bridge View Object
Building a DCOM Client that access an existing CORBA Server
• Obtain the MIDL definition for all types defined in the corresponding OMG IDL file in the CORBA server
• Compile the MIDL file (create proxy/stub code and other supporting files to be used by the client)
• Register types in the Bridge (cputidl AddressBook.idl)• Build the Proxy/Stub DLL• Implement the client
Implementation of DCOM Client accessing a CORBA Server
• The client obtains a COM View object in the Bridgethat can forward requests to the CORBA server
• The COM View object instantiates a CORBA Factory object in the Bridge by calling CoCreateInstanceEx(IID_ICORBAFactory, …)
• The client calls GetObject() on the CORBA factory object, passing the name of the target object in the CORBA server, and returns the object reference to the target object in the CORBA server
Bridge
CORBA Server
IIOP DCOM
DCOM Client
CORBA Object Reference
COM Interface pointer
COM View
TargetCORBA Object
DCOM Client to CORBA Server
DCOM Client
Reference to factory
Reference toBookKeeper
To BookKeeperobject in remoteCORBA server
Bridge
FactoryObject
COM ViewIBookKeeper
1
23
Binding the DCOM Client to a CORBA Object
A VB Client that Accesses the CORBA Server
A CORBA Client that Accesses the CORBA Server
Conclusions• Both CORBA and DCOM provides functions for
achieving the transparent activation and accessing of remote objects. However, they provides its own programming interfaces, uses its own IDL languages, support its own data type, and uses its own wire protocols. They have their own advantages and disadvantages.
• CORBA and DCOM can be bridged to work together
• The interworking of CORBA and DCOM can take the advantages of DCOM’s strength in visual component development and CORBA’s strength in flexibility and services
Future Work
• The Bridge solution to CORBA/DCOM interworking imposes a significant amount of communication overhead. A middleware that natively supports both CORBA and DCOM will be the future. This type of future middleware should support both CORBA and DCOM at the IDL level.