Copyright © Environmental Systems Research Institute
The Microsoft Component Object Model
ArcObjects is based on Microsoft's Component Object Model (COM). End users of ArcGIS applications don't necessarily have to understand COM, but if you're a developer intent on developing applications based on ArcObjects or extending the existing ArcMap and ArcCatalog applications using ArcObjects, an understanding of COM is a requirement. The level of understanding required depends on the depth of customization or development you wish to undertake. Although this topic does not cover the entire COM environment, it provides both Visual Basic and Visual C++ developers with sufficient knowledge to be effective in using ArcObjects. There are many coding tips and guidelines that should make your work with ArcObjects
Before discussing COM specifically, it is worth considering the wider use of software components in general. There are a number of factors driving the motivation behind software components, but the principal one is the fact that software development is a costly and time-consuming venture. In an ideal world, it should be possible to write a piece of code once and then reuse it again and again using a variety of development tools, even in circumstances that the original developer did not foresee. Ideally, changes to the code's functionality made by the original developer could be deployed without requiring existing users to change or recompile their code.
Early attempts at producing reusable chunks of code revolved around the creation of class libraries, usually developed in C++. These early attempts suffered from several limitations, notably: difficulty of sharing parts of the system (it is very difficult to share binary C++ components— most attempts have only shared source code), problems of persistence and updating C++ components without recompiling, lack of good modeling languages and tools, and proprietary interfaces and customization tools.
To counteract these and other problems, many software engineers have adopted component-based approaches to system development. A software component is a binary unit of reusable code.
Several different but overlapping standards have emerged for developing and sharing components. For building interactive desktop applications, Microsoft's COM is the de facto standard. On the Internet, Javasoft's Java Beans is viable technology. At a coarser grain appropriate for application-level interoperability, the Object Management Group (OMG) has specified the Common Object Request Broker Architecture (CORBA).
ESRI chose COM as the component technology for ArcGIS because it is a mature technology that offers good performance, many of today's development tools support it, and there are a multitude of third-party components that can be used to extend the functionality of ArcObjects.
To understand COM (and therefore all COM-based technologies), it's important to realize that it isn't an object-oriented language, but a protocol or standard. COM is more than just a technology; it is a methodology of software development. COM defines a protocol that connects one software component, or module, with another. By making use of this protocol, it's possible to build reusable software components that can be dynamically interchanged in a distributed system. COM also defines a programming model, known as interface based programming. Objects encapsulate the manipulation methods and the data that characterize each instantiated object behind a well-defined interface. This promotes structured and safe system development, since the client of an object is protected from knowing any of the details of how a particular method is implemented. COM doesn't specify how an application should be structured. As an application programmer working with COM, language, structure, and implementation details are left up to you
The key to the success of components is that they implement, in a very practical way, many of the object-oriented principles now commonly accepted in software engineering. Components facilitate software reuse because they are self-contained building blocks that can easily be assembled into larger systems.
COM does specify an object model and programming requirements that enable COM objects to interact with other COM objects. These objects can be within a single process, in other processes, or even on remote machines. They can be written in other languages and may have been developed in very different ways. That is why COM is referred to as a binary specification or standard—it is a standard that applies after a program has been translated to binary machine code.
COM allows these objects to be reused at a binary level, meaning that third party developers do not require access to source code, header files, or object libraries in order to extend the system even at the lowest level.