VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

Systems Analysis - System analysis and Design tutorial for Software Engineering

You are here: Visual Basic > Advanced VB6 tutorial > Chapter 16

Understanding the MTS Runtime Environment

A careful look at the MTS runtime environment will help to make the distinctions necessary to develop an MTS-specific component. When a client calls an MTS object, the object does not receive those calls directly. Instead, an MTS process stands between the client and the object. This architecture allows MTS to provide the following services:
  • Automatic management of object instances

    MTS will automatically track all instances of objects, no matter how many clients are using the objects. Related to this feature, MTS provides the component developer with control over how long an object’s associated resources are kept alive.

  • Automatic management of processes and threads

    Depending on the thread model used by the component, MTS will create threads as necessary to ensure that object code executes efficiently.

  • Distributed, atomic transactions for underlying data sources

    MTS allows objects to take advantage of the transaction features provided by the underlying data services. A transaction is said to be atomic when all the work done in association with the transaction is done as a group. In other words, if any single aspect of the transaction fails, the entire transaction is rolled back.

  • Built-in user security

    MTS provides a simple way for security to be applied to MTS components by taking advantage of underlying Windows NT security structures.

MTS objects that run on the local machine of the client may run inprocess or in separate processes configured by the server. If the object will be running on a remote MTS machine, MTS must run it in a server process. Packages in which components will run in-process are referred to as Library Packages. If the components in the package are to be run out of the client process, the package is referred to as a Server Package. Exactly how the component will run can be configured in MTS Explorer from the package’s Properties dialog box. Figure 16.3 shows the Activation tab, which is part of the Properties window of a package in MTS Explorer.

The Activation tab enables you to choose which activation type should be applied to the package. This in turn will determine whether its components will run in-process or as separate processes.
FIGURE 16.3 The Activation tab enables you to choose which activation type should be applied to the package. This in turn will determine whether its components will run in-process or as separate processes.

Context Object

As previously noted, MTS will track object instances, allow a transaction to be associated with the object, and keep track of security. Internally, MTS does this through what is known as a Context object. Every MTS object will always have a Context object. Context objects are created and associated with an MTS object automatically by the MTS runtime environment. The Context object is used by MTS to identify any transaction that the MTS object is participating in. It is directly involved with committing or rolling back the transactions. Furthermore, it also maintains the state of security properties.

From a component developer’s perspective, the presence of the Context object introduces unique elements into COM component development. In particular, by taking advantage of the functionality available in the Context object, a component can be designed to be stateless. In other words, an object can be designed to release any resources it is using for internal variables, properties, ODBC connections, and so on. This is something that is usually done when a transaction is either completed or when it fails. This is a departure from the way other COM components (said to be stateful) are developed. Stateful objects retain resources until the object is destroyed. Hence, stateless objects provide the most scalable solution. With stateless objects, clients can create an instance of an object and use the object to perform transactions. Because the object’s resources are released when the transaction is complete, there is no cost in not immediately destroying the object. Of course, there are implications for the client as well, in that any properties lose their values when the transaction is complete.

Resource Dispensers

Another core topic that helps the developer to understand the runtime environment is, what’s known as, a Resource Dispenser. A Resource Dispenser manages shared states for components. In other words, if components have similar uses for the same resource, such as a global property or database connection, they can share it. An important example is the ODBC Resource Dispenser. The ODBC Resource Dispenser provides components with two key benefits:

  • Components will automatically share ODBC connections, which greatly reduces what is traditionally considered a huge cost for enterprise applications.

  • If the MTS component is configured to use a transaction, the activity performed by the ODBC connections on behalf of the component will automatically be enlisted in the transaction.

In a nutshell, the ODBC Resource Dispenser helps to provide a reliable infrastructure that frees the developer to focus on the business logic. A second example of a Resource Dispenser is the Shared Property Manager. By default, each instance of an object is isolated from other instances of the same object. In other words, properties exposed by objects are only accessible to the client that instantiated the object. The Shared Property Manager provides a standard way for developers to allow MTS objects from different clients to share property information with each other. This way, a developer can circumvent the default isolation provided to each instance of an object.


<< Previous | Contents | Next >>

Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved