COM on UNIX

Some applications simply need to access applications running on other platforms. We'll call these non-Windows applications legacy applications, just to distinguish them from the MTS-based applications we've been discussing in this book. (No insult intended.) Rather than implement code that uses a low-level network protocol or proprietary API to communicate between these applications, you might want to use COM as the communication mechanism. COM components can be implemented on the legacy application platform to wrap access to the legacy applications. New applications create objects using the COM wrapper components and communicate with the objects via Distributed COM (DCOM). Internally, the wrapper methods call the native API exposed by the application. The primary reason for using this technique is to provide a consistent programming model for new applications. Developers do not need to learn a new protocol or API to talk to the legacy application, they simply use COM. Writing COM components for other platforms is conceptually no different from writing components on Microsoft Windows, although different programming tools are used. Once a COM wrapper is in place, the legacy application functionality is accessible to rapid application development (RAD) tools such as Microsoft Visual Basic and possibly to scripting languages—for example, to server-side scripts in an ASP page.

Although COM is often thought of as a Windows-only technology, it is available on a number of other platforms. As of April 1998, COM is available for the Solaris platform directly from Microsoft and for Solaris, Linux, and MVS from Software AG. Microsoft plans to release COM for other UNIX platforms later in 1998. Microsoft has also licensed the COM source code to a number of independent software vendors (ISVs) and operating system vendors. These vendors will provide COM implementations directly on platforms such as Silicon Graphics IRIX.

COM implementations on non-Windows platforms include the basic functionality of COM for instantiating and using objects as well as structured storage, monikers, custom marshaling, connectable objects, Automation, and Uniform Data Transfer (UDT). These features are more than sufficient for building components to interoperate with Windows DNA applications.