This document describes how the NGWS runtime interacts with all external entities, including classic COM, external libraries, and the operating system. The document covers how the NGWS runtime exposes its services externally, as well as how Runtime can access services exposed by the external environment.
The external view of the runtime will be especially important to classic COM clients that need access to objects inside the runtime. Since it’s unrealistic to expect both the client and server portions of existing applications to be upgraded to NGWS at the same time, we have to assume there will be a period when servers live within the Runtime and clients remain classic COM. During this period, it’s important that these hybrid applications continue to operate normally without affecting the classic COM client. The fact that these new objects have a different implementation must be completely transparent to existing clients.
Equally important is the need for new Runtime clients to have access to the services provided by classic COM servers. Again, it’s unrealistic to expect all classic COM servers to be upgraded to NGWS overnight. For one reason or another, some classic COM servers may never be upgraded to NGWS. Others may be upgraded to NGWS over an extended period of time. Regardless of how simple it is to migrate from classic COM to NGWS, there will be a period when NGWS clients need the services provided by classic COM servers. Therefore, the objects contained within a classic COM server need to be exposed within the runtime in such a way that they appear to be true NGWS objects.
One determining factor in how fast servers are upgraded is the amount of effort needed to do the upgrade. Therefore, NGWS interoperability must also ensure that the process of migrating from classic COM to NGWS is as simple and effortless as possible. While most of the work involved in the migration is language or tool dependent, the NGWS frameworks and runtime team can also take steps to simplify this process.