This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!
Component Services Scenarios
Bank Sample Components
The bank sample has four components:
Bank. Uses MoveMoney to transfer money between two accounts.
MoveMoney. Transfers money between two accounts. Subtracts from one, then adds to another. Hosted in Windows 2000 Component Services and requires a transaction.
Account. Posts a change in money to a specified account using ADO+. This can be positive or negative. Hosted in Windows 2000 Component Services and requires a transaction.
Database. Tables that hold bank account details including balances in a database.

Upgrade Scenarios
One scenario of steps to consider:
- Start. All the class COM components are written in VB6.
- Bank is upgraded to a NGWS runtime language such as VB7 or C#.
- MoveMoney is upgraded to a NGWS runtime language.
- Account is upgraded to a NGWS runtime language.
Another scenario of steps to consider:
- Start. All the class COM components are written in VB6.
- MoveMoney is upgraded to a NGWS runtime language.
Calling between Classic COM and NGWS components
Classic COM component calling a NGWS Component
- A CCW (Com Callable Wrapper) provides a COM Proxy that makes the NGWS component look to classic COM as a regular classic COM object. The CCW is used to make the transition between unmanaged code and managed code.
- The NGWS SDK tools TLBEXP is used to generate the TLB from the NGWS Components MetaData.
- Classic COM supports interfaces with methods and properties. Classic COM does not support fields, statics or type hierarchies, so these elements on NGWS components are not accessible from classic COM.
- The default interface can be thought of as the class interface.
- For the classic COM component to communicate with the NGWS component, the NGWS component needs to registered with classic COM.
- For the NGWS Component to be hosted in Windows 2000 Component Services it needs to be configured in the Windows 2000 Component Services catalog.
NGWS Component calling a Classic COM component
- A RCW (Runtime Callable Wrapper) provides a Managed “Proxy” that looks like a NGWS component to other runtime code. The RCW is used to make the transition between managed code and unmanaged code when the NGWS component calls the classic COM Component.
- Classic COM supports interfaces with methods and properties. Classic COM does not support fields, statics or type hierarchies.
- Just like today, the classic COM component is registered with classic COM.
- For the classic COM Components to be hosted in Windows 2000 Component Services it needs to be configured in the Windows 2000 Component Services catalog.
- For the NGWS Component to be hosted in Windows 2000 Component Services it needs to be registered in the Windows 2000 Component Services catalog.
NGWS Component calling NGWS Component
- NGWS Components support a high fidelity object model: class hierarchies, interfaces, methods, properties, fields and statics.
- Today classic COM components have the restriction that only interfaces elements (methods and properties) are supported. For PDC Tech Preview, NGWS Components hosted in Windows 2000 Components Services have the same restriction i.e. only interface elements (methods, properties) are callable. The NG Component may still have fields, class hierarchies etc, but they are not accessible from other NGWS Components. In Product Release, the full fidelity (class hierarchies, interfaces, methods, properties, fields, etc) of the object model will be available. This is detailed in the paper below.
- For the NGWS Component to be hosted in Windows 2000 Component Services it needs to be registered in the Windows 2000 Component Services catalog.
Statics
The behavior of static methods (and static fields) is pretty much the same in PDC Tech Preview and Product Release. Unmanaged clients can never access managed statics.
Managed clients can access managed statics directly (note that statics are scoped per AppDomain), subject to accessibility controls like private/public, of course. Such access never goes through any kind of remoting boundary, including Windows 2000 Component Services Contexts (aka COM+ 1.0 contexts). Indeed, the access is always to a local type. So the access bypasses any semantics associated with the context.
Historically, MTS and COM+ 1.0 programmers are aware of the fact that global functions are part of their implementation, and they are unrelated to the context boundaries. They are also aware of the fact that they can accidentally leak references across boundaries using globals. In the managed world, most of those restrictions remain for statics.
However, things will be slightly brighter in this regard, after the planned enhancements for ComEmulate is done for the product release (ComEmulate is a custom attribute used to mark types (classes) that enable COM+ 1.0 Services on manage code classes.
At that point, references will go through a transition or not, based on whether the thread is already in the correct context. It won't be possible to leak a direct reference via a static, because in the managed world the clients will *never* have a truly direct reference to an instance of a ComEmulate type.