This post has already been read 2321 times!
COM and DNA Before the development of .NET, COM and DNA technologies were used for application development on Microsoft platforms. COM is Microsoft’s framework for developing and supporting program component objects. DNA is a framework that integrates Web applications with the n-tier model of development. It is used to develop cost-effective solutions that can meet the demands of the Internet, intranet, global e-commerce, and corporate computing. Note : Windows DNA is short for Windows Distributed interNet Applications Architecture, a marketing name for a collection of Microsoft technologies that enable the Windows platform and the Internet to work together. Some of the principal technologies comprising DNA include ActiveX, Dynamic HTML (DHTML) and COM. Windows DNA has been largely superseded by the Microsoft .NET Framework, and Microsoft no longer uses the term.
Drawbacks of Pre .NET Technologies Programmers mostly used Microsoft Visual Basic (VB) and Microsoft Visual C++ (VC++) for developing applications using the COM/DNA technologies. However, these technologies and the programming languages had several drawbacks. (Windows DNA is short for Windows Distributed interNet Applications Architecture, a marketing name for a collection of Microsoft technologies that enable the Windows platform and the Internet to work together. Some of the principal technologies comprising DNA include ActiveX, Dynamic HTML (DHTML) and COM. Windows DNA has been largely superseded by the Microsoft .NET Framework, and Microsoft no longer uses the term.)
Limitations of VC++ in COM/DNA Applications The other language used by programmers to work with COM and DNA applications was VC++. However, VC++ is a complex language. It has too many data types. Additionally, exchange of data between different layers was difficult because of data type compatibility issues. To resolve such issues, developers had to be familiar with various libraries, such as Software Development Kit (SDK), Microsoft Foundation Class (MFC), Active Template Library (ATL), and COM.
Drawbacks of COM/DNA Apart from the limitations resulting from VB and VC++, the COM/DNA technologies had several other drawbacks. These drawbacks became apparent as these technologies were extended into larger enterprise-level settings and as integration with the Internet became necessary. Some such drawbacks of COM/DNA technologies included difficulty in integrating Internet technologies, difficulty in side-by-side execution of components, and deployment issues.
Difficulty in Integrating Internet Technologies The growth of the Internet has lead to the need of a tool for developing Internet-based technologies. To address this need, Microsoft developed ASP. However, ASP was not meant for structured and object-oriented development. It was also difficult to design, debug, and maintain ASP code. The existing technologies lacked the ability to communicate with users through HyperText Transfer Protocol (HTTP) and HyperText Markup Language (HTML). Developers required a standard that could enable processes to communicate over the Internet. However, COM and DNA did not provide any such standard.
Difficulty in Side-by-Side Execution of Components With DNA, it is difficult to have side-by-side execution of components. In side-by-side execution of components, different versions of a component can coexist and run simultaneously on the same machine and within the same process. When a new application is installed with DNA, it overwrites the existing version of the shared component with a new version of the component. Usually, the new version is not backward-compatible with the existing applications. Therefore, though the new application works, existing applications that depend on the old version start functioning incorrectly or stop functioning completely.
COM and Deployment COM components are difficult to deploy. The COM standard was developed for use on systems having limited memory and was designed with a focus on memory sharing between applications. The Dynamic Link Libraries (DLLs) on such systems were shared between applications to save memory.
Deployment Issues The process of sharing DLLs between applications resulted in several deployment issues. DLLs had to be registered in the local Windows Registry so that components required to run an application could be located quickly. This resulted in other limitations. For instance, you could not place a COM application on a CD-ROM or a network drive and then run it from that location without an installation procedure.