COM

In-Place Activation Linking Embedding Drag and Drop Automation Uniform Data Transfer Persistent Storage Monikers Component Object Model Compound Documents COM OLE

A remoting architecture provides the foundation for a distributed object system. The differences between COM and CORBA are largely syntactic The general mechanisms and functionality that are provided by COM and CORBA are quite similar. The fundamental traits of a distributed object system includes: Interfaces Interfaces are used to define contracts that describe the capabilities of the distributed objects in the system. Interfaces are used in both COM and CORBA to define such contracts

Datatypes A distributed object system must support data types that allow data to be transmitted to and from the distributed objects. Both COM and CORBA provide for a rich set of types as well as support for enumerated types, constants and structures. Marshaling & Unmarshaling A distributed object system must ensure that data integrity is maintained when data is transmitted to and from distributed objects. A marshaling process packages data into a standard format so that it can be transmitted. An unmarshaling process unpacks transmitted data.

Proxies, Stubs and Skeletons A distributed object system abstracts access to distributed objects so that the objects can be treated uniformly by client applications. COM and CORBA provide seamless access to distributed objects by proxifying client access to remote objects. Proxies, Stubs and skeletons are the terms used in COM and CORBA for the mechanisms that allow seamless access to remote object Object Handles Object handles are used to reference distributed object instances within the context of a client’s programming language or script. These are referred to as interface pointers in COM and as object references in CORBA

Object Creation A distributed object system must provide a mechanism for creating a new instance of a distributed object. A factory is a special type of distributed object used to create other distributed objects. COM defines a standard factory interface for all COM objects, while CORBA factory interfaces are user-defined . Object Invocation A distributed system must provide a mechanism for invoking operations on a distributed object Both COM and CORBA provide mechanisms that allow for static and dynamic invocations of distributed objects.

Object Destruction A distributed object system must provide a mechanism for removing a distributed object instance from the system once it is no longer in use. COM supports distributed reference counting and garbage collection CORBA provides no system support (i.e.) distributed objects remain alive forever unless explicitly evicted or timed out.

Both COM and CORBA supports a rich set of datatypes. This includes constants, enumerated types, structures, and arrays in addition to common base types like long and short. COM It has a special subset of data types known as automation types that must be used when defining automation-compatible interfaces. The limitation of this type is the lack of support for user-defined types such as “structs” COM interfaces that are not automation-compatible often do not work with non C++ COM client environments including VB. CORBA Here, CORBA is superior to COM. Any CORBA type can be used in any CORBA interfaces.

COM IDL and Type Libraries All of the IDL code will be generated by VC++ from within an Active Template Library (ATL) project . The creation of properties, methods, interfaces and so forth was completely dialog driven . Otherwise, remembering the various keywords and syntax is quite challenging. In developing client applications, a COM IDL description is often not needed at all. For example, VB client application requires no interaction with the IDL description of the COM object. Because it relies on a type library .

A type library is a compiled binary file that contains a standardized description of a COM object. Type libraries can be created from an IDL file using the Microsoft IDL (MIDL) compiler . The command c:/sample>midl SamServer.idl results in creation of several files, including a type library named SamServer.tlb. After the type library has been created, its location needs to be registered in the windows system registry It can then be used by client applications to programmatically obtain the COM object.

The IDL file is divided into two parts: Contains a list of interfaces to be supported by the COM object. Define a type library contains a single coclass (Component Object Class) that will implement a COM object supporting the interfaces. Each COM IDL interface definition is divided into a header and a body .

IAccount Interface is given below, [ object, uuid(B5F3E2FE-B376-1101-BBIE-00207812E629), oleautomation, helpstring(“IAccount Interface”), pointer_default(unique) ] interface IAccount: IUnKnown { [propget, helpstring(“property Balance”) ] HRESULT Balance([out,retval] double *pVal); [propget, helpstring(“property Name”)] HRESULT Name([out,retval] BSTR *pVal); [helpstring(“method Deposit”)] HRESULT Deposit ([in] double amount); [helpstring (“method withdraw”)] HRESULT Withdraw ([in] double amount); };

object Signifies that the interface is a COM interface (as opposed to DCE interface) uuid (universal unique identifier) Specifies a unique 16-byte identifier for the interface. It is generated by a utility and computed based on the machine’s network address and time stamp . It is used within the COM runtime systems as well as the Windows System Registry to uniquely identify the interface.

oleautomation Specifies that all data types used are automation types . This attribute guarantees that the interface can be used in Visual Basic It also allows the automation marshaler to be used with the interface helpstring Specifies a descriptive string to be placed in the type library. pointer_default Used to optimize proxy and stub code that is generated by the MIDL compiler .

CORBA IDL CORBA Specification is vendor neutral . So, this not depend on vendor-specific tools or specific operating system features like the Windows System Registry . CORBA IDL code is much simpler than COM IDL code. This focuses strictly on interface definition , whereas COM IDL is used to address many non-interface related issues (e.g. type libraries) CORBA focuses mainly on distributed objects and not on in-process objects (such as optimization of Active X control) CORBA relies on multiple inheritance , whereas COM relies on the notion of multiple distinct interface.

The COM and CORBA architectures allow developers to treat distributed objects as native objects . Both COM and CORBA rely on client-side and server-side mechanisms to manage remoting issues . These mechanisms are referred to as stubs and skeletons in CORBA and proxies and stubs in COM. Communication Bus (DCOM or CORBA) Client Stub (COM Proxy) (CORBA Stub) Server Stub (COM Stub) (CORBA Skeleton) Client Server

A remote method invocation is implemented as follows: A client invokes a remote method. The remote method is actually invoked in the client stub . The client stub creates a message containing information needed for the remote invocation . (The message creation process is referred to as marshaling ) The client stub sends the message to the server stub using the communication bus . The server stub receives the message and unpacks it. The server stub calls the appropriate server method based on the information provided in the received message . The server stub creates a message based on the outputs of the call to the server method . The server stub sends the result message to the client stub using the communication bus . The client stub receives the result message , unpacks the message and returns the result to the client.

In COM, the proxy and stub are packaged in a single DLL . The DLL is associated with the appropriate interfaces in the Windows System Registry . The COM runtime system then uses the registry to locate proxy-stub DLLs associated with an interface when marshaling of the interface is required. The proxy stub code is generated by running the MIDL compiler, on the IDL file. Ex: c:\book\code>midl BookServer.idl The following files will be generated: BookServer.h BookServer_i.c BookServer_p.c dlldata.c

Once the DLL is built, proxy-stub DLL should be registered in the Windows System Registry To register regsrv32 utility can be used. Ex: c:\book\code>regsrv32 BookServer.dll The proxy-stub DLL must be installed on every client machine, so that the client application can properly marshal data. Fig. shows Using a COM Proxy-Stub DLL COM/DCOM Proxy (BookServer.dll) Stub (BookServer.dll) Client (VB or C++ Client) Server (VC++ COM Server) COM/DCOM RPC

The creation and registration of a proxy-stub DLL does not require always. Instead, it can rely on a technique known as type library marshaling . The type library is generated by the MIDL compiler The type library needs to be registered in the Windows System Registry on all client machines so that it can be used by the VB client application. ( oleautomation enabled) To register the type library the utility named regtlb can be used: c:\book\code> regtlb BookServer.tlb An added benefit of using automation-compatible types and registering a type library is that the automation marshaler can be used instead of proxy-stub DLL .

The automation marshaler (implemented in oleaut32.dll ) uses the type library to marshal data between client and server – no proxy-stub DLL is required. Fig. shows the automation marshaler. COM/DCOM COM/DCOM Proxy (oleaut32.dll) Stub (oleaut32.dll) Client (VB or C++ Client) Server (VC++, COM Server) RPC Type Library (BookServer.tlb) Type Library (BookServer.tlb)

Packaging of the stubs and skeletons is user-defined . In c++, object files are created and in Java, a package is created with all the stub files needed for the Java Client . To generate the Orbix Stub and skeleton the Orbix IDL compiler can be used: C:\Orbix\bin\idl.exe –B test.idl The following files are generated: test.hh testC.cpp testS.cpp Orbix ORB (C++) Orbix ORB (C++) Stub testC.obj Skeleton testS.obj Client (Orbix C++ Client) Server (Orbix C++ Server) IIOP

Java Client requires a VisiBroker Client Stub. To generate the VisiBroker stub: Ex: C:\Vbroker\bin\idl2java ..\..\server\idl\Sample.idl The idl2java compiler generates a Java package named test corresponding to the test IDL module. This contains the stub classes needed for the VisiBroker Java Client. The VisiBroker and Orbix ORBs communicate using IIOP . Orbix ORB (C++) VisiBroker ORB (Java) Stub test Java Package Skeleton testS.obj Client (VisiBroker Java Client) Server (Orbix C++ Server) IIOP

The COM and CORBA IDL descriptions provide the basic for COM and CORBA servers. Implementing a COM server is simply a matter of defining the IDL within a Visual C++ ATL project and then filling in the methods that are automatically created by VC++ and the ATL wizard. Implementing CORBA server requires a different approach. Rather than generating the IDL and server simultaneously, the following are needed: Create the IDL description using a generic editor . This is vendor and implementation neutral Compile IDL description using the IDL compiler that is provided with the Orbix product. This generates *.hh, *S.cpp and *C.cpp Implement the server using the files generated with an orbix specific implementation approach.

To avoid being distracted by any code not related to distributed objects, all possible wrapper classes should be created. Using IDL in the COM C++ Client To communicate with the COM object, the wrapper class needs to be able to declare and use interface pointers . So, it must know the uuid s corresponding to the interfaces and the component class . Where do the uuid and the declarations come from? Generate the required definitions from the IDL files (OR) Use the previously generated type library.

Using the COM object in C++ client is fairly easy. VB makes even easier. VB relies on the type library that registered in the Windows System Registry when the ATL COM Server is created. To use the type library, enable it in the References dialog box from within the client application’s project. This is accomplished by selecting References from the VB project menu and enabling the object’s type library of that object. To confirm it open the Visual Basic Object Browser and look for the COM object over there.

The Wrapper class relies on files that are generated by the IDL Compiler. First Run the Orbix IDL Compiler on the IDL file. The IDL compiler generates several files, including a header file named *.hh , it will be included in the wrapper class header file. This file defines all the symbols (class definitions, constants, etc.) necessary to work with the CORBA object. The IDL compiler also generates a file named *C.cpp . This file contains the client stub that allows the client application to plug into the Orbix ORB . And also the *S.cpp file contains the skeleton .

CORBA IDL is not vendor-specific . The VisiBroker compiler is invoked using the command idl2java . In java, CORBA IDL modules map directly to Java Packages . The import statement can import that package directly into the program.

These are used to reference object instances in a programming language context. An object handle in C++ is an object pointer or an object reference . In VB, it is a variable referring to a VB object. To simplify access to distributed objects, object handles referring to COM and CORBA objects need to behave much like their native counterparts. COM interface pointers An interface pointer refers a specific COM object instance COM object instance supports multiple interfaces In calling methods on a COM object, it is usually necessary to use multiple interface pointers that point to different interfaces for the same object instance. A COM object instance uses reference counting to determine when it should be destroyed .

The IUnknown interface defines two methods for reference counting: AddRef() and Release() . AddRef() is called implicitly when a COM object is created and also when a QueryInterface() call success. AddRef() should be called explicitly whenever a copy of the interface pointer is made. Release() is used to decrement the reference count and should be called whenever an interface pointer is no longer in use. In general, reference counting is problematic when the programmer is made responsible for adding and releasing references. To avoid the problems of this method smart pointers can be used. Smart pointers automatically increment and decrement reference counts .

CORBA Object References In CORBA with C++, reference counting directly affects how object references are declared. An object reference type that is appended with _ptr never implicitly affects the reference count of the object that it references. An object reference type that is appended with _var implicitly decrements the reference count of any object it currently references when it is destroyed or assigned to a new object. Managing CORBA object references in C++ is hard . The complexity due to reference counting is one factor that makes CORBA C++ a poor choice for the client tier in an N-tier system. So, in this case Java can be the best choice.

Contd… The java runtime environment provides many advantages over its C++ counterpart. When it comes to CORBA, one of the most important advantage is Java’s support for garbage collection . Java based CORBA products rely on the Java run-time system to manage CORBA object reference counting. Garbage collection is used to determine when a CORBA object is no longer referenced .

Creating Objects Creating new instances is done easily by using the new operator. But in distributed object, different process on different machine is needed. COM and CORBA rely on an abstraction called a factory to create distributed object instances. A factory is a special type of distributed object whose main purpose is to create other distributed objects. Creating a distributed object in COM and CORBA is a two-step process. The appropriate factory is located. The factory is used to create the object of interest.

COM Factories COM defines a standard interface for factories called IClassFactory A typical COM server implements the IClassFactory interface, thereby allowing COM object instances to be created. The creation process for COM objects that rely on IClassFactory is always the same. Use the COM object CLSID (i.e., uuid of the coclass ) to obtain an IClassFactory interface pointer to the correct factory. Call the IClassFactory::CreateInstance() method to create the COM object instance. After the COM object is created, an interface pointer to the newly created object instance is returned, and the factory interface pointer is discarded.

CORBA Factories CORBA does not specify a standard implementation for factories. Instead, CORBA provides for persistent objects (i.e., object that can live beyond the lifetime of a single process.) A persistent object provides a useful mechanism for creating a factory . The CORBA clients rely on a stringfied interoperable object reference (IOR). A stringfied IOR is simply a string of characters that can be used to uniquely identify a CORBA object instance available on the network regardless of vendor (or) hardware platform An alternative to using the file-based IOR would be to register the factory instance with a CORBA Naming Service (COS). Clients could then use the naming service to find the instance .

Invoking Object Methods Once an object handle has been obtained for a COM or CORBA object, invoking methods on that object is simple. A major goal of both COM and CORBA is to make remote method invocation as easy as local method invocation . The DCOM extensions to COM mandate that every COM interface method return a 32-bit integer known as HRESULT . The HRESULT contains status information indicating the success or failure of the call and also allows customized HRESULT values . In contrast, CORBA supports an exception based model . It defines a standard exception types such as the CORBA SystemException when mapping CORBA IDL to C++ and Java. It also allows user to declare new exception types in CORBA IDL.

COM HRESULTs A COM HRESULT is a simple, efficient and effective means for conveying status . An HRESULT is a 32-bit integer that is divided into three fields . The most significant bit (bit 31) indicates severity -either success or an error. Bit 16-30 indicate the facility (e.g. RPC, win 32 etc.) with which the HRESULT is associated. Bits 0-15 indicate a specific return code for the facility. Because only one bit is used to indicate success or failure. DCOM mandates that every COM interface method return an HRESULT. In the event that an error occurs within DCOM during method invocation, the DCOM runtime return its own error code indicating the problem that occurred. retval used to store the HRESULT value of each method.

Creating a user defined HRESULT for general use in a system requires some care: The user must decide whether the HRESULT indicates success or an error. The user should use the FACILITY_ITF constant. This indicates that the HRESULT is specific to the interface that defines the method. The user should select a return code between 0x0200 and 0x0FFF since all return code between 0x0000 and 0x01FF are already reserved by COM for the FACILITY_ITF facility.

CORBA provides robust support for exceptions . In addition to standard system exception types defined in the C++ and Java mappings for CORBA IDL, the CORBA standard also allows for user-defined exceptions . An IDL exception can contain members of any IDL datatype, including simple types, structs, unions, enums, and references to other CORBA objects. InvalideNameException contains one member called reason . This allows the CORBA server object to pass a reason back to the client if the exception is raised. The InvalidNameException is thrown by the init() method defined in the main interface. CORBA method invocations from C++ and Java should always made within a try-catch block . Failure to catch an exception thrown by the CORBA runtime will result in abnormal program termination CORA heavily relies on exceptions , and Java provides much better exception support than C++.

In C++, an object is destroyed using the delete operator. In Java, the garbage collector locates objects no longer in use and destroys them. COM supports distributed reference counting and garbage collection where by a sever object is destroyed when there are no longer any clients referencing it. COM’s built-in management of object destruction is an extremely useful and important feature. In CORBA, sever-side reference counts are maintained separately and have no direct relationship to client-side reference counts . The reference count maintained in a CORBA server for a specific instance can be manipulated only within the context of the server. This means that the responsibility for releasing all references to a server object requires a customized solution rather than a standardized approach .

COM normally destroys a COM server object instance when there are no longer any clients referencing it. The Nothing values is used in VB to disassociate an object Reference from the actual object. Setting a COM interface pointer to Nothing effectively calls Release() on that interface pointer. COM uses two mechanisms to determine when a COM object instance needs to be destroyed. A COM object instance maintains one reference count in the server that is directly manipulated by all clients of the instance. In reality, this could result in a network traffic . For this reason, COM caches calls to AddRef() and Release(), in order to optimize traffic between the clients and server. To handle situations like network outages, COM uses a pinging mechanism to determine when clients can no longer access a server.

Contd… Clients are expected to ping the server periodically (e.g. every 2 min.) to let the server know that they are still using the server. If a COM server does not receive a ping within a fixed number of ping periods, it assumes that the client can no longer access the server object . If no other clients hold references to the server object instance, the instance is destroyed . Pinging a potentially expensive when the number of clients and servers are more. To overcome this problem, COM uses an important optimization strategy called delta-pinging . Delta pinging combines client ping requests that are destined for the same server machine into a single ping set . Another optimization strategy used by COM combines delta-pings with normal COM packets thus reducing ping overhead.

Destroying Objects – CORBA… A CORBA object’s server-side reference count is initialized when the object is created. A CORBA object’s server-side reference count is initialized when the object is created. _duplicate() call will increases the counter by 1. CORBA/C++ memory management rules dictate that release() will be called on a _ptr type returned by a server method, and decreased by 1. The destroy() method calls the release() on the CORBA server instance, and reduces counter by 1. To remove the unused CORBA object instances, the CORBA developer is required to implement an eviction scheme within the CORBA server. These schemes are based on timeouts.

Contd… An eviction might work as follows: Server maintains a list of object references and time stamps for all object instances created in the server. The timestamp is used to indicate the last time the object instance was invoked. A timeout value is set to 10min. A sweep method run every 2 min that evicts objects not used within the last 10 min. To keep the server object instance alive the object provides a method called keepAlive() that must be called every 10 minutes by the client if no other method are invoked. The CORBA standard does not define a specific method for handling object destruction.

COM – CORBA Comparison Trait Similarities Differences Interfaces Each uses their own IDL to describe interfaces. CORBA IDL is simpler an elegant than COM IDL COM has better tool support for creating and managing IDL than CORBA Datatypes Both support a rich set of data types Both also support constants, enumerated types, structures and arrays. COM has automation types. Automation compatible interfaces are supported in more client environments than non-compatible interfaces. Because the non-compatible interfaces are not guaranteed to work other than C++. Any CORBA interface can be used from any CORBA client

COM – CORBA Contd… Trait Similarities Differences Proxies, Stubs & Skeletons COM and CORBA rely on client stubs and server stubs to handle remoting issues. COM & CORBA generate client stubs and server stubs from IDL. COM client & server stubs are called as Proxy & Stub and in CORBA called as Stub & Skeleton. COM proxy-stub DLLs are used by all language environments. In CORBA, a separate stub-skeleton must be generated for each ORB/language combination. Marshaling & Unmarshaling COM and CORBA handle marshaling in client stubs and server stubs. Users do not need to worry about marshaling. COM allows automation-compatible interfaces to use type library marshaling, thus eliminating the need for customized stubs.

COM – CORBA Contd… Trait Similarities Differences Object Handles COM & CORBA support reference counted handles on object instances. COM calls object handles as interface pointers and CORBA calls as object references. CORBA supports multiple inheritance in the interface hierarchy. COM supports single inheritance only; however a COM object supports one ore more distinct interfaces. Object Creation Both use factories to create objects instances. COM has a standard factory interface called IClassFactory CORBA factories are customized persistent CORBA objects.

COM – CORBA Contd… Trait Similarities Differences Object Invocation Both allow for method invocation similar to native environment method invocation. COM’s error-handling mechanism is based on HRESULT return values. CORBA supports user-defined exception types in IDL. Object Destruction COM and CORBA rely on reference counting to determine when an object can be destroyed COM supports distributed reference counting and garbage collection. CORBA reference counts are maintained separately in the client and server.

COM

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to COM (20)

More from Roy Antony Arnold G (20)

Recently uploaded (20)

COM