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!

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:

  1. Start. All the class COM components are written in VB6.
  2. Bank is upgraded to a NGWS runtime language such as VB7 or C#.
  3. MoveMoney is upgraded to a NGWS runtime language.
  4. Account is upgraded to a NGWS runtime language.

Another scenario of steps to consider:

  1. Start. All the class COM components are written in VB6.
  2. MoveMoney is upgraded to a NGWS runtime language.

Calling between Classic COM and NGWS components

Classic COM component calling a NGWS Component

NGWS Component calling a Classic COM component

NGWS Component calling NGWS Component

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.