Designing the CML Components and Objects

After the CML developers determined what each component should do, they defined the properties, methods, and events for each class module. They selected the transactional behavior for each component, and looked at the tasks grouped together in a component. When reuse is the ultimate purpose of application components, developers should consider the granularity of the component carefully. Components that are discrete in purpose are easier to reuse.

Keep the following in mind when designing components to use with Microsoft Transaction Server (MTS):

• Declare MTS transactional behavior. Operations within an object should relate to transactions in a consistent way. Four options are available: requires transactions, requires new transaction, supports transactions, and does not support transactions. Insertions, updates, and deletions are transactional operations. Separating operations by their transactional requirements makes a lot of sense. Designing objects by their relationship to transactions allows for implementation of transactions where transactions are of benefit; a fetching operation clearly cannot benefit from any transactional behavior.
• All components implemented in MTS are in-process components.
• Define the MTS packages in which this application will implement each component. Packages encapsulate components for installation, locally or remotely as a group. A package can have one or more components, and a component can participate in any number of packages. The CML Admin, Search, and User components are in one MTS package, CML.pak.

Do the following when designing components and objects:

• Define the properties for each class. Using properties implies that the component will be kept around for the duration of the process. The methods of the CML classes will accept parameters and not rely on property values.
• Define the methods for each class.
• Decide to use the Optional keyword for some parameters. None of the CML parameters are implemented as Optional, though the ability to do so is available to the procedure. This flexibility allows a greater possibility of reusing the component.
• Decide how many DLLs you will implement. The CML application uses two DLLs, one client-side (CMLC.dll), and one server-side (CML.dll). In the CML application the User and Admin components can readily use the methods and properties of the TableQueue object because they are contained in the same DLL.
• Decide how the components will be accessed. Each component has an Instancing property value. The Admin, Search, User, and UserInfo objects are MultiUse and allow other applications to create objects from the class. The TableQueue and MTSEnvironment are Private and other applications aren't allowed access to type library information about the class, and cannot create instances of it.