COMPARISON AND BRIDGE BETWEEN CORBA AND DCOM

1. COMPARISON AND BRIDGE BETWEEN CORBA AND DCOM Wenjie Lin Directed by Dr. W. Homer Carlisle Nov. 18, 1998

2. 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.

3. 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

4. Questions • What differences are there between CORBA and DCOM ? • Can these two systems work together? • How can these two systems work together?

5. Agenda • CORBA Overview • COM/DCOM Overview • A Comparison between CORBA and DCOM • CORBA/DCOM Bridge

6. CORBA Overview

7. CORBA Architecture

8. 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.

9. CORBA Static Method Invocation

10. CORBA Dynamic Method Invocation

12. Clients Object Implementations Static IDL Stubs Dynamic Invocation Interface Static IDL Skeleton Dynamic Skeleton Interfaces ORB Interface Object Adapters Object Request Broker ORB Interface Repository Implementation Repository

13. 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

14. 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

15. Client Operation Invocations Implementation Object BookKeeperImplementation.java TIE Object IDL Interface _tie_BookKepper.java Server Implementation - TIE approach

16. 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

19. COM/DCOM Overview

20. COM Basics • Access to an object only through interfaces • A COM interface is structured as a table ofpointer 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

21. COM Interface Pointer and vtable

22. IUnknown Interface Interface IUnknown { HRESULT QueryInterface(IID& iid, void **ppv); ULONG AddRef(void); ULONG Release(void); }

23. COM Client Server Binary Code Interface pointer CLSID COM Library CLSID System Registry Server binary code Creation of COM Objects

24. COM Library Function for Object Creation HRESULT CoCreateInstance { REFCLSID clsid, LPUNKNOWN *pUnkOuter, DWORD dwClsCtx, REFIID riid, LPVOID *ppv, };

25. DCOM - COM With a Longer Wire

26. DCOM Architecture

27. API function for Creating a COM object on Remote Machines HRESULT CoCreateInstanceEx ( REFCLSID clsid, LPUNKNOWN *pUnkOuter, DWORD dwClsCtx, COSERVERINFO * pServerInfo, ULONG cmq, MULTI_QI rgmq[] );

28. 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

29. 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++

30. A Comparison between CORBA and DCOM

31. 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

32. 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

33. 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

34. 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.

35. 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

36. 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

37. 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.

38. CORBA/DCOM Bridge

39. 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

40. The Solution is to make CORBA/DCOM working together

41. How ?

42. COM/CORBA Interworking through Bridge

43. The Interworking Model

44. OrbixCOMet Bridge View Object

45. 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

46. 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

47. DCOM Client to CORBA Server

48. Binding the DCOM Client to a CORBA Object

49. A VB Client that Accesses the CORBA Server

50. A CORBA Client that Accesses the CORBA Server