NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Goals

Coexistence of classic COM and the NGWS Runtime

With the NGWS frameworks and runtime fully installed on a computer, all classic COM applications must continue to work, without modification, in exactly the same way they worked before the runtime was installed.

Upgraded COM Server Compatibility

Classic COM clients must continue to work in exactly the same way when their respective classic COM servers are upgraded to run in the NGWS runtime environment. The client must be completely unaffected by the upgrade of the server. This implies that the set of interfaces exposed by the runtime on behalf of the new NGWS runtime server must be binary compatible to the set of interfaces exposed by the older version of the same server. In addition, all other aspects of the interaction between the client and server must also be identical, including discovery, activation, location transparency, error handling, synchronization, eventing, and lifetime management.

This requirement does not imply that the NGWS runtime server must be source code compatible with the classic COM server. Source code compatibility depends on the tools used to create the server.

Upgraded COM Client Compatibility

Classic COM servers must continue to work in exactly the same way when their respective classic COM clients are upgraded to run in the NGWS runtime environment. The server must be completely unaffected by the upgrade of the client. This implies that the NGWS classes exposed by the runtime on behalf of the classic COM server are binary compatible to the set of interfaces exposed to the older version of the same client. In addition, all other aspects of the interaction between client and server must be identical, including discovery, activation, location transparency, error handling, sinkhronization, eventing and lifetime management.

This requirement does not imply that the NGWS runtime client must be source code compatible with the classic COM client. Source code compatibility depends on the tools used to create the client.

Mixed Client/Server Compatibility

A NGWS runtime server that is capable of serving multiple clients must be capable of serving both classic COM clients and runtime clients simultaneously. It should be transparent to the server that some of its clients are classic COM, while others are Runtime clients. Both types of clients must be able to use the same instance of a particular NGWS runtime server at the same time.

The reverse also applies. A NGWS runtime client that is capable of interacting with multiple COM servers must be able to interact with both classic COM servers and NGWS runtime servers simultaneously. This flexibility allows some classic COM servers to be upgraded without requiring that every server used by a particular application be upgraded at once. The fact that one server was upgraded while others remain classic should be transparent to the client applications.

Performance Targets

The performance of the NGWS runtime interoperability layer is absolutely critical to the success of the NGWS frameworks and runtime. While marshaling calls between classic COM and the NGWS runtime is expected to be slower than marshaling in classic COM, we expect this extra overhead to be offset by improved performance within the runtime, so that the overall performance of a reasonably complex method call will remain the same. The raw overhead of an in-process, direct vtable bound method call between classic COM and the NGWS runtime with simple scalar data types for parameters should be on the order of 10 machine instructions. Considering that the overhead in classic COM is a single jump instruction, our goal of 10 instructions can add significantly to the call overhead when the amount work done within a method call is very small. However, typical method calls are more complex, and therefore the impact of 10 instructions should be negligible when compared to the number of instruction executed within such calls.

The overhead on late bound method calls should be not noticeable.