Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. COMPARISON AND BRIDGEBETWEEN CORBA AND DCOM Wenjie Lin Directed by Dr. W. Homer Carlisle Nov. 18, 1998
  2. 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. 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. 4. Questions• What differences are there between CORBA and DCOM ?• Can these two systems work together?• How can these two systems work together?
  5. 5. Agenda• CORBA Overview• COM/DCOM Overview• A Comparison between CORBA and DCOM• CORBA/DCOM Bridge
  6. 6. CORBA Overview
  7. 7. CORBAFacilities Vertical FacilitiesApplication Horizontal Facilities Objects User Information Systems Task Interface Management Management Management Object Request BrokerNaming Trading Life cycle Persistence Event Transaction Security Concurrency Relationship Query Event Licensing Properties Time Externalization CORBAServices CORBA Architecture
  8. 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. 9. CORBA Static Method Invocation Client Host Server Host Client Object Client Object Stub Skeleton Code Code Function Call Object Request Broker
  10. 10. CORBA Dynamic Method Invocation Client Host Server Host Client Object Dynamic Object Invocation Skeleton Interface Code Function Call Object Request Broker
  11. 11. 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); };};
  12. 12. Clients Object ImplementationsStatic Dynamic ORB Object Static DynamicIDL Invocation IDL Skeleton Interface AdaptersStubs Interface Skeleton Interfaces Object Request Broker ORB Interface Repository Implementation Repository
  13. 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. 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. 15. Server Implementation - TIE approach Client Client Operation Implementation Implementation Operation ObjectInvocations Invocations Object IDL TIE TIE Interface Object Object
  16. 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
  17. 17. 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); };};
  18. 18. COM/DCOM Overview
  19. 19. 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
  20. 20. COM Interface Pointer and vtable pFuncA FuncA pFuncB FuncB Pointer pFuncC FuncC tointerface … … Object with vtable member functions
  21. 21. IUnknown InterfaceInterface IUnknown{ HRESULT QueryInterface(IID& iid, void **ppv); ULONG AddRef(void); ULONG Release(void);}
  22. 22. Creation of COM Objects COM COM Client Server Server Client Binary BinaryInterface pointer Code Code CLSID CLSID COM COM System System Library Library Registry Registry Server binary code
  23. 23. COM Library Function for Object Creation HRESULT CoCreateInstance { REFCLSID clsid, LPUNKNOWN *pUnkOuter, DWORD dwClsCtx, REFIID riid, LPVOID *ppv, };
  24. 24. DCOM- COM With a Longer Wire
  25. 25. Client Proxy Object Stub Component Security Security"CoCreateI DCE RPC DCE RPC Provider Provider nstance" Protocol Stack Protocol StackOLE32 "CoCreateInstance" (Remote) Activation SCM SCM DCOM network- protocol DCOM Architecture
  26. 26. API function for Creatinga COM object on Remote MachinesHRESULT CoCreateInstanceEx ( REFCLSID clsid, LPUNKNOWN *pUnkOuter, DWORD dwClsCtx, COSERVERINFO * pServerInfo, ULONG cmq, MULTI_QI rgmq[]);
  27. 27. 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
  28. 28. 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++
  29. 29. A Comparisonbetween CORBA and DCOM
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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.
  34. 34. 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
  35. 35. 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
  36. 36. 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.
  37. 37. CORBA/DCOM Bridge
  38. 38. 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
  39. 39. The Solution isto make CORBA/DCOM working together
  40. 40. How ?
  41. 41. COM/CORBA Interworking through Bridge
  42. 42. The Interworking ModelObject Model A (client) Object Model B (Server)Object reference in A View of Target Target Object object Object reference in B
  43. 43. OrbixCOMet Bridge View Object COM Interface DCOM CORBAAutomation Interface Object Object Bridge View Object
  44. 44. 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
  45. 45. Implementation of DCOM Client accessing a CORBA Server• The client obtains a COM View object in the Bridge that 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
  46. 46. DCOM Client to CORBA ServerCORBA Server DCOM Client Target IIOP Bridge DCOM CORBA Object COM Interface pointer CORBA Object COM View Reference
  47. 47. Binding the DCOM Client to a CORBA Object DCOM Client To BookKeeper Reference Reference to object in remote to factory BookKeeper CORBA server 2 3 Factory 1 COM View Object IBookKeeper Bridge
  48. 48. A VB Client that Accesses the CORBA Server
  49. 49. A CORBA Client that Accesses the CORBA Server
  50. 50. 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
  51. 51. 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.